#rC3 - Ramming Enclave Gates: A Systematic Vulnerability Assessment of TEE Shielding Runtimes

[Translated by Kari Kananoja (ITKST56 course assignment at JYU.FI)] Alkumusiikkia

Seuraavassa keskustelussamme on mukana Jo Van Bulk ja Fritz Adler
belgialaisesta Leuvenin

yliopistosta ja David Oswald, kyberturvallisuuden
professori Birminghamista.

He ovat täällä keskustelemassa luotetusta toiminto/ajoympäristöstä (TEE)
(laitteen eristetty prosessorin osa, johon esim. laitteen käyttöjärjestelmällä ei ole pääsyä).

Tiedättekin varmasti Intelin ja vastaavien perusteella, että siihen eli luultavasti pitäisi luottaa lainkaan,

koska se on ohjelmoitua ja siinä on virheensä. Niinpä he puhuvatkin nyt

prosessorin enklaaviportteihin iskemisestä,
mikä on aina hyvä, järjestelmällisen haavoittuvuuden

arviointikohde TEEn suojauksessa. Olkaa hyvät ja jatkakaa.

Hei kaikille. Tervetuloa mukaan keskusteluun. Olen Jo, imec-DistriNet

tutkimusryhmän perustaja Leuvenin yliopistolla.
Ja tänään mukana on myös Fritz, myös Leuvenista

ja David Birminghamin yliopistosta. Meillä on tämä hyvin kiinnostava

aihe keskusteltavana, enklaaviportteihin iskeminen. Mutta ennen kuin syvennymme siihen,

uskon että suurin osa teistä
ei tiedä mitä ovat enklaavit, tai yleensä TEEt

Joten aloitankin tässä analogialla. Enklaavit ovat eräänlaisia

turvallisuuslinnakkeita prosessoreissa, CPUissa.
Se on siis kryptattu muistialue,

johon on pääsy vain TEEn sisäpuolelta. Mitä tiedämme

linnoitusten puolustautumisen ja niihin hyökkäysten historiasta, kun et

pääse linnoitukseen koska seinät ovat korkeita ja paksuja. parasta onkin suunnata porteille.

Se on linnoituksen heikoin kohta. Ja se on

tämän aiheemme idea. Se siis pätee myös enklaaveihin. Me olemme

iskeneet enklaavien portteihin, olemme hyökänneet syöte- ja tulosterajapintoihin.

Siis hyvin yksinkertainen idea, mutta dramaattiset vaikutukset, sanoisin.

Tämä on siis jonkinlainen päätelmä tutkimuksistamme. 40 rajapinnan

huoltoon liittyvää
haavoittuvuutta jotka löysimme kahdeksassa paljon käytetyssä openvapaan lähdekoodin

projektissa. Menemme tähän hiukan syvemmälle lopuissa dioissa.

On mukavaa sanoa, että
se on johtanut kahteen akateemiseen julkaisuun,

enemmän kuin 7 CVE-tietoon ja
kokonaisuudessaan melko hallittuun loppuun käsittelyyn ja

pitkiin käytön rajoituksiin.
OK, Meidän täytynee

keskustella miksi me yleensä tarvitsemme moisia enklaavi linnoituksia.
Jos mietitään

Jos mietitään perinteistä käyttöjärjestelmä-tai tietokonearkkitehtuuria, siinä on

käytössä
hyvin laaja luotettu toimintoperusta. Esimerkiksi, jos katselet tätä keskustelua esim. kannettavalta

luotat kerneliin,
luotat ehkä

virtuaalikoneeseen jos sinulla on koko ympäristö toteutettuna: CPU,

muisti, ehkä kovalevy
ja niin edelleen. Toisin sanoen

ongelma on tällaisen laajan luotetun ympäristön kanssa se, että myös

haavoittuvuuksia voi olla
kaikkialla. Ja myös haittaohjelmia piiloutuneena missä tahansa osassa.

Enklaavissa ajamisen ideana on siis, esimerkiksi Intel SQX:ssä,

yhdessä viimeisimmistä Intelin prosessoreista,
että voit ottaa

varsinaisen sovelluksen ohjelmistopinon osan suoritettavaksi enklaavin

ulos koko koneen
luotetusta ympäristöstä. Nyt sinun tarvitsee luottaa ainoastaan CPU:hun ja tietenkin

omaan koodiisi, mutta itse
käyttöjärjestelmään ei enää tarvitse luottaa. SGX

esimerkiksi lupaa suojella toimintoa hyökkääjältä, joka on saanut
haltuunsa pääkäyttäjän tiedot.

Ja riippuen myös siitä, ketä vastaan olet puolustautumassa, esimerkiksi,

haitallisten pilvipalveluiden toimittajilta. Joten ajattelepa, että voit ajaa applikaatiota pilvessä

ja voit silti ajaa koodiasi luotettavasti laitteistotason
eristyksellä.

Ja sinulla on myös todisteet siitä. Eikä enää tarvitse luottaa edes

pääkäyttäjään. Näin ollen ongelma on tietenkin, että hyökkäyspinta

säilyy. Niinpä ainakin osa aiemmista hyökkäyksistä, joita
esitellään tässäkin

etäkongressissa tänä vuonna, on suuntautunut CPU:n

mikroarkkitehtuuria kohtaan.Eli hyökätään
periaatteessa laitetasolle. Teillä oli

oli siis ennakointia, mikroarkkitehturaalista tiedon keruuta, haamuja, ladatun
arvon injektointia jne.

Mutta mihin on vähemmän kiinnitetty huomiota ja mihin kiinnitämme enemmän huomiota tässä

huomiota tässä esittelyssä, on ohjelmistotaso
enklaavin sisällä. Siellä on viitattu olevan

luotettua koodia. Mutta nyt voidaankin katsoa tarkemmin,

mitä enklaavin
sisällä on. Nyt ohjelmistonäkökulmasta. Siis voiko

hyökkääjä hyväksikäyttää mitään perinteistä
ohjelmistohaavoittuvuutta enklaavissa?

Kyllä, David. Tämä on mielenkiintoinen näkökulma, eikö totta? Puhutaanpa siis

ohjelmistoista. Meidän täytyy ymmärtää mikä on ohjelmistoympäristö näille

SGX enklaaveille ja
luotetuille ajoympäristöille yleisesti. Ja tätä me selvitimme. Aloitimme

analysoinnilla ja tässä muutamia
kuvakaappauksia. Tämä on itse asiassa kasvava

vapaan lähdekoodin ekosysteemi, monia ajo-ohjelmistoja,
kirjastokäyttöjärjestelmiä ja ohjelmistokehitysympäristöjä.

Ja ennen kuin menemme syvemmälle, haluan painottaa, että mikä on yhteinen tekijä

joka kaikkia näitä yhdistää?
Mikä on näiden ympäristöjen alkuperäinen ajatus ja idea?

Mikä tahansa TEE, luotettu ajoympäristö,

antaa käsityksen
siitä, mikä on turvallinen suojapaikka vihamielisessä

ympäristössä. Ja voit suorittaa toimintoja suojatussa osiossa
kun

ympäröivä maailma palaa. Minkä tahansa suojausmekanismin kohdalla, kuten jo aiemmin mainitsin,

paholainen piilee
yksityiskohdissa ja tyypillisesti portilla, eikö totta? Miten siis välität tietoa

tämän epäluotettavan maailman joka palaa, ja enklaavissa olevan turvapaikan välillä?

Ja
intuitio kertoo, että että tarvitset jonkinlaisen välillä olevan ohjelmistokerroksen,

jota kutsumme suojaustasoksi.
Se tekee tavallaan turvallisen

sillan liikkua ympäristöstä toiseen. Ja siitä

olemme kiinnostuneita. Nähdäksemme, millaisia tarkistuksia siellä tarvitaan.

Sinulla on melko kaunis kuva asiasta, toisaalla hedelmällinen enklaavi ja

toisaalla vihamielinen aavikko. Ja tähän
tehdään turvallinen silta väliin. Ja mistä

olemme kiinnostuneita, kun jokin menee vikaan? Mitä jos sinun siltasi onkin viallinen?

Vastataksemme kysymykseen, katsotaan sitä välissä olevaa laatikkoa ja kysytään,

millaista ylläpitoa ja millaisia tarkistuksia täytyy olla jotta edestakainen

liikenne on mahdollista?
Ja yksi

pääasiallisista tuloksistamme, joita olemme saavuttaneet tämän tutkimuksen kahtena viimeisenä vuotena, on mielestäni

että tuo välilaatikko voidaan jakaa kahteen alemman tason kerrokseen.

Näistä ensimmäinen on ABI, sovelluksen binäärirajapinta, hyvin alhainen CPUn tila. Ja

toinen on mitä kutsumme APIksi,
sovelluksen ohjelmointirajapinta.

Tuo tila tai vaiheet on jo nähtävissä ohjelmointikielissä. Kuten

esittelyssä mainittiin, me tavallaan ohjaamme teidät
läpi molempiin tasoihin asiaankuuluvien

haavoittuvuuksien avulla, jotta ymmärrettäisiin mitä tämä tarkoittaa.

Ensiksi Fritz ohjaa teidät mielenkiintoiseen ABI-tason alempaan toimintakenttään.

Kyllä vaan. Ja kuten Jo jo mainitsitkin,

se on CPUn tila ja sovelluksen binäärirajapinta. Mutta katsotaanpa

hiukan mistä puhutaan. Periaatteessa se tarkoittaa sitä, että hyökkääjä

hallitsee CPUn rekistereiden sisältöä....Jokaisella enklaavin sisään- ja ulostulolla

täytyy suorittaa tehtäviä. Eli enklaavilla ja

luotetulla ajoympäristöllä
on tietty CPU vaihe ja kääntäjä voi

työskennellä niiden kutsujen kanssa, joita se odottaa. Nämä ovat siis avainosia.

Meidän täytyy alustaa CPU rekisterit enklaaviin saapuessamme ja

siivota ne poistuessamme. emme voi siis olettaa mitään

hyökkääjän meille antamaa annetuksi. Meidän täytyy alustaa se joksikin kunnolliseksi ja käytettäväksi.

Tutkimme useita TEE ajoympäristöjä ja löysimme paljon

haavoittuvuuksia tältä ABI kerrokselta. Ja yksi tämän tutkimuksen
pääoivalluksista onkin se

että monet näistä haavoittuvuuksista sijoittuu monimutkaisien ohjesarjojen prosessoreihin,

siis CISC ja SGT TEE:issä. Tutkimme myös joitain

RISC prosessoreita, ja vaikka ei pidä yleistää, niin on heti huomattavissa,

että monimutkaisella x86 ABIlla on huomattavasti suurempi

hyökkäyspinta-ala kuin yksinkertaisemmissa
RISC arkkitehtuureissa. Katsotaanpa yhtä esimerkkiä tästä

monimutkaisesta arkkitehtuurista.
Esimerkiksi x86:ssa merkkijono ohjeistus,

jota säätelevät suuntaliput. X86:ssa on erityinen ohjeistus, joka

periaatteessa mahdollistaa striimatut muistitoiminnot. Jos bufferiin

tehdään muistin käsittelyyn toimintosarja, se käännetään merkkijonon toiminto-ohjeeksi.

Merkkijono siis luetaan vasemmalta oikealle ja ylikirjoitetaan

muistin käsittelysarjan toiminnolla. Mutta tuo lippu mahdollistaa myös käsittelyn päinvastoin,

takaperin. Ei ajatella sitä miksi tämä oli hyvä ajatus tai mihin sitä

tarvitaan. Mutta varmasti on siis mahdollisuus kääntää lippu toiseen asentoon ja lukea

bufferin sisältö takaperin. Ja mitä me
huomasimme: System-V ABIn mukaan

tämä lippu täytyy olla asettamatta tai olla asetettu eteenpäin(vasemmalta oikealle).

Ja kääntäjä olettaa tämän olevan näin. Katsotaanpa kuinka tämä tapahtuu

enklaavissa. Jos ajamme tämän enklaavin sisällä, luotetussa ympäristössä

normaalilla syötteellä normaalilla

normaalilla lipulla, voimme nähdä, että ajo

tapahtuu aivan oletetusti oikein päin. Jos hyökkääjä kuitenkin pääsee

ja muuttaa lippuasetuksen toiseksi,

ja pointerin kohdasta riippuen näemme ajon nyt menevän takaisinpäin luennassa.

Siinä on ongelma. ja sitä emme selvästikään

halua tapahtuvan luotetussa sovelluksessamme, koska

koska kuten voitte kuvitella,
se mahdollistaa niiden avainten ylikirjoittamisen,

jotka ovat muistipaikassa, jossa voit lukea takaperin.

Se mahdollistaa tiedon ulosluvun eikä se ole hyödyllistä. Kun saimme tämän raportoitua, se

johti CVE:n syntymiseen korkealla score-arvolla, kuten näette seuraavalla dialla.

Ja se on vain yksi instanssi. Täytyyhän tässä ajatella nyt

kaikkia lippuasetuksia joita täytyy ylläpitää ja tarkistaa. Mutta, tietenkin

on aina vielä jotain muutakin, eikö totta?
Huomasimme myös,

että FPU:ssa (matemaattisten toimintojen osaprosessointi) on paljon muita rekistereitä ja paljon
muita

haavoittuvuuksia hyväksikäytettävänä. Enkä mene nyt yksityiskohtiin. Mutta tähän nyt

vielä lisäksi, on olemassa
vanhempi x86 ja ja uudempi SSE

jotka suorittavat liukulukulaskentaa.
Eli on olemassa FPU ohjaussana ja MXCSR

rekisteri näitä uudempia ohjeita varten. Ja tämä x86 on vanhempi, mutta sitä yhä käytetään

esim. pitkien double muuttujien laskennassa. Eli ikä ei

tässä kohtaa ole määrittelevää, koska niin vanha kuin uusikin on tässä tapauksessa yhä ajankohtaisia.

X86 ja x87 ovat yhä olemassa ja se että voitaisiin sanoa että vanhat muinaiset jotka ovat

vanhentuneita, ovatkin yhä
käytössä ja siten huomioitava. Jos katsotaan

System-V ABIa, huomasimme että nämä ohjausbitit ovat kutsujatallenteisia.
Niitä siis

säilytetään läpi funktiokutsujen.
Ja ideanahan on, mitä pidetään jossain määrin saavutuksena,

että nämä ovat globaaleja tiloja, niitä välitetään

koko sovellukselle. Yksi sovellus voi siis asettaa arvon

ja se pysyy läpi niiden käyttöajan.
Mutta ongelma on, kuten näette

on että sovelluksemme tai enklaavimme on periaatteessa yksi sovelluskokonaisuus, emmekä todellakaan halua

hyökkääjän ottavan haltuunsa luotettua sovellustamme, eikö totta?

Mitä siis tapahtuu jos FPU asetukset säilytetään eri kutsujen ajan?

Sanotaanko että normaalikäyttäjälle, teemme laskentaa enklaavissa. Kuten

2.1 kertaa 3.4 on 7.14, mikä on tyyppinä pitkä double.

Tämä on OK? Mutta mitä tapahtuu jos hyökkääjä saapuu enklaaviin

mukanaan saastutettuja määritelmiä FPU:lle? Saamme vääristyneitä

tuloksia ja huonommalla tarkkuudella.

Itse asiassa tässä se pyöristää alaspäin, aina kun

tulos ylittää tarkkuuden. Ja sitähän emme halua? Tämä on jotain,

missä kehittäjä odottaa tiettyä tarkkuutta tai pitkän doublen tarkkuutta,

mutta hyökkääjä itse asiassa
supistaa tulosta ja sen tarkkuutta.

Raportoimme tästä ja itse asiassa löysimme tämän aiheen myös Microsoft OpenEnclavesta. Siksi

tätä ei ole merkitty hyväksikäytön mahdollisuudeksi. Mutta mitä huomioimme mielenkiintoisena kohtana on, että Intel

SGX SDK, joka oli haavoittuvainen, korjasi tämän xrstore
ohjeella.

Tämä säilyttää täysin tilan tiettynä arvona, kun taas OpenEnclave

säilytti vain tietyn rekisteriarvon, joka oli kohteena, ldmxcst ohjeessa.

Ohitetaanpa muutama dia tässä vaiheessa, koska haluan

painottaa, että tämä ei ollut tarpeeksi.
Huomiomme mukaan, vaikka tämä tietty rekisteri säilytettiin,

on muita rekistereitä,

joita voi merkitä käytössä oleviksi
ennen enklaaviin saapumista, ja johon hyökkääjä voi

muuttaa laskentatuloksen ei-numeraaliseksi. Tämä on hiljaista,

eikä siis ohjelmointikieliriippuvaista, eikä kehittäjäriippuvaista. Tämä on

hiljainen ABI asia, että laskenta ei ole ainoastaan numeroita.

Raportoimme myös tämän. Ja nyt, onneksi, kaikki enklaaviympäristöt käyttävät tätä täyttä xrstor ohjetta.

säilyttääkseen tämän laajennetun tilan. Siihen vaadittiin kaksi CVE:tä, mutta nyt

ne suorittavat täyden hallinnan. En halua mennä nyt tutkimustemme ytimeen, vaan

haluan nyt osoittaa näiden tutkimuksiemme tarkoituksen.

Tutkimme näitä tapahtumia ja halusimme selvittää,

ovatko ne vain vaikeita vaiko huonoja toteutuksia. Huomasimmekin,
että

ylivuotoja voidaan käyttää sivukanavana salaisuuksien päättelemiseen. Esimerkiksi,

hyökkääjä voisi käyttää
rekisteriä poikkeusten paljastamiseen jotta

sitten enklaavin sisällä voitaisiin laukaista syöteriippuvaisesti kerrontaa.

Lisäksi havaitsimme, että näiden sivukanavien kautta voidaan

käyttää syötetilan binäärietsintään.

Ja me voimme
palauttaa tämän moninkertaistamisen määriteltyihin

määrään vaiheita. Jos meillä on vain yksi maski, jonka käännämme voimme

itse asiassa palauttaa toiminnon määriteltyihin vaiheisiin.

Ja jotta tietäisimme, voimme tehdä myös enemmän. Voimme suorittaa myös koneoppimista

enklaavissa.
Jo mainitsikin, että sitä voidaan tehdä TEEn sisällä, pilvessä. Ja

se on koneoppimisessa mukavaa, eikö totta? Tehdäänpä hiukan käsinkirjoitetun luvun

tunnistamista. Jos ajattelemme mallia, jossa toinen

käyttäjä käyttää
koneoppimismallia

ja toinen käyttää enklaavia.

Kaikki on turvallista, mutta huomasimme, että voimme saastuttaa näitä FPU

rekistereitä ja näin alentaa
koneoppimisen suorituskykyöä

siten, että vain 8 prosenttia merkeistä tulkitaan oikein. Ja

kaikki luvut olivat itse asiassa tuloksissa samoja,

joten tämä koneoppiminen on tässä kohtaa hyödytöntä, eikö vain? Lisäksi voimme

hyökätä kuvamuutoksia sekoittamalla, pienien kuvamuutosten ja sekoitettujen kuvien

välillä. Tämä, jotta nähtäisiin, että on pieni mutta monimutkainen asia

ja ilmaisee että kaikki voi mennä pieleen nopeasti ABI tasolla, jos siellä puuhailee.

Tässä on kyse siis CPU tiloista. Nyt voidaankin puhua lisää

sovellusten ohjelmointi rajapinnasta, joka onkin
hiukan mukavampi

aihe olettaisin.
Joo, otetaan vaan, kiitos

Otetaanpa tähän melko yksinkertainen esimerkki.

Oletetaan, että lataamme standardin unix binäärin enklaaviin, ja siellä on toiminnot sitä varten,

vaikkapa graphene.
Ja mitä haluan esittää tällä esimerkillä;

On hyvin tärkeää tarkistaa, mistä osoittimet ovat lähtöisin. Koska

enklaavi tavallaan osittaa muistin luotettuun enklaaviin ja ei-luotettuun muistiin,

ne ovat erillisissä muistialueissa. Ongelma tässä on seuraava; Oletetaan että

meillä on binäärin kaiutus, joka ainoastaan tuo näytölle input-arvon. Annamme toiminnolle argumenttinä
merkkijonon

ja se normaalisti kaiuttaa sanotaanko "Hello, world", merkkijonon joka on ei-luotetussa

muistissa. Kaikki sujuu kuten pitääkin,

enklaavissa ajetaan komennot, se saa pointerin ulkopuoliseen muistiin ja printtaa merkkijonon.

Ongelmana on kuitenkin se, että enklaavilla on pääsy

myös omaan suojattuun muistiinsa. Jos hyökkääjä pääsee

käsiksi pointeriin ja ohjaa sen jonkin suojattavan tiedon kohtaan,

toiminto printtaa tiedon ulos, eikö niin? Eli äkkiä tämä onkin muuttunut muistin

sulku haavoittuvuudeksi. Ja se nähdään tässä

tapahtumassa mainitsemassani graphene ympäristössä. Meillä on siis

yksinkertainen hello world -merkkijono ja sitä käsitellään parin argumentin avulla.

Ja nyt, muutamme enklaavin ulkopuolella pointeria

enklaavin muistissa. Seurauksena se printtaa halutun

sijasta enklaavin
muistissa sijaitsevan suojatun tiedon.

suojatun tiedon. Tämän tyyppiset haavoittuvuudet

ovat melko tunnettuja kernelien tutkinnasta ja muistakin yhteyksistä. Niitä

kutsutaan niemllä confused deputy ( hämmentynyt apulaissheriffi). Sheriffillä on ase lukemiseen,
mutta ei

tiedäkään ongelman sattuessa mitä tehdä,

kun ei alun perin tarkistanut kenelle muistipaikka kuuluu tai kuka sitä hallitsee.

Tämä haavoittuvuus tuntuisi olevan helposti ratkaistavissa. Yksinkertaisesti

tarkistetaan koko ajan mitä osoitin tulee. Mutta kuten sanottu,

se ei aina ole helppoa. Kyllä David, on melko
tarkkanäköistä,

jos sanoo että meidän tulisi tarkistaa kaikki osoittimet. Niinpä me teimmekin.Tarkistimme kaikki

pointereihin liittyvät tarkistukset ja huomasimme että Endolla on mielenkiintoinen tapa

tarkistaa nämä kaikki. Toki, koodi on korkealaatuista. He tarkistivat

kaikki pointerit, mutta asioiden eteen on tehtävä jotain erityistä. Puhumme nyt

C ohjelmointikielestä. Käsittelyä ei siis erityisesti päätetä.

Ne loppuvat uuteen tavuun ja funktiota voidaan käyttää samalla kun taistellaan

tiedon pituuden kanssa. Ja miten tarkistus tehdään, kun tieto

on täysin muistialueen ulkopuolella?
Ensimmäinen askel on käsitellä pituus,

se on 10, ja sitten tarkistetaan alkaako ja loppuuko tietoalue

kokonaan kohteen ulkopuolella. Kuulostaa paikkansapitävältä. Sitten päästetään

höyryä. Tuntuu toimivan hienosti. Kuinka tämä toimii,

kun yhdistetään eri ajoympäristöt. Emmekä nyt ajattele sitä, että koko setup on enklaavin ulkopuolella,

johon salattu merkkijono välitetään.
Ensimmäinen askel

on enklaavin aloittama käsittely merkkijonon pituuden suhteen.

Kuulostaa melko mehukkaalta, mutta
onneksi kaikki

menee hyvin, kun huomataan että koko toimintoa ei olisi pitänyt tehdäkään ja

koko toiminto on itse asiassa enklaavin sisällä. Pyyntö siis hylätään

merkkijonon suhteen. Eli OK. Mutta kuten jotkut teistä tietävät,

tämä on mielenkiitoista, koska
English kilpaili asiasta,

mistä ei koskaan pitänyt.
Ja tuon kilpailun pituus määrittyy

1-bittien määrästä tehtäväannossa. Eli meillä on tässä sivukanava, jossa English

palauttaa aina arvon False. Mutta aika, joka

tuon arvon määrittämiseen menee, riippuu 0-tavujen määrästä Arncliffe

muistiblokissa. Sen me löysimme. Olimme innoissamme ja sanoimme sen olevan yksinkertainen aikaikkunaongelma.

Tällä mennään, eli tuon teimme ja näette sen tässä graafissa,

ja se osoittautui hankalammaksi kuin miltä näyttää. Sininen

1 mittaisen merkkijonon ja tuo on 2-mittaisen merkkijonon. Mutta

mitenkään ei voida graafista päätellä, koska siinä 6 prosessoria toimii

kovalla vauhdilla ja että yksi lisäys on täysin

hävinnyt kanavaan. Sitä ei pysty selvittämään mittamalla käsittelyaikaa.

Tarvitaan siis jotain muuta. Meillähän on viisaita kirjoituksia

kirjallisuudessa, esimerkiksi hyvin yleisistä hyökkäyksistä ASICeihin, joista myös Intel kirjoittaa.

Voitte nähdä, mitkä muistiblokkien sivut ovat käytössä, kun

English ajaa, koska hallitset käyttöjärjestelmää ja
sivutusmekanismeja.

Sitä siis yritimme tehdä ajatellen että se onkin mukava sivukanava.

Raavimme päätämme katsoessamme yksinkertaista ja lyhyttä luuppia koodissa,

ja lyhyttä merkkijonoa joka sopii kokonaisuudessaan yhdelle muistisivulle.

Vaikka meillä on pääsy muistiin, se ei auta meitä tässä, koska

koodi ja data mahtuvat molemmat samalla sivulle.

Tämä on siis väliaikainen ratkaisu, se ei ole tarpeeksi tarkka.

Eli paljon on käsiteltävää ja olemme toimineet mielenkiintoisessa

ympäristössä. Se käyttää epäsuoria osoituksia ja sitä sanotaan isoksi askeleeksi. Se on siis

täydellinen viitekehys esimerkiksi Hadoopissa. Ja mitä se itse asiallisesi mahdollistaa

sinun tehdä, on ajaa enklaavia askel kerrallaan, nimestään huolimatta.
Se siis myös mahdollistaa

hyökkääjän puuttumisen koodin ajoon jokaisen ohjeen tai käskyn välissä.

Ja miten me sen esitämme, on hyvin teknistä. Meillä on Linuxin kernelin

ajo pienen kirjastokäyttöjärjestelmän ympärillä, mutta se

ei ole ihan asian ydin. Asia on siinä, että voimme pysäyttää enklaavin

jokaisen komennon jälkeen ja rauhassa pohtia, mitä voisimme tehdä.

Mitä me ite asiassa voimme tehdä, on ajaa ja seurata tätä lisäkoodia

yksi kerrallaan ja jokaisen keskeytyksen jälkeen
yksinkertaisesti tarkistaa,

saavuttaako enklaavi merkkijonon sieltä mihin olemme sen osoittaneet.
Se on toinen

tapa ajatella asiaa, että meillä on ajo enklaavissa ja se voidaan rikkoa

osiin ja laskea osat.

Päättäväistä ajoittamista. Tosin sanoen meillä on ennustaja joka kertoo

missä 0-tavut sijaitsevat. En tiedä onko se käytännöllistä, itse asiassa on.
Osoittautuu

olevan niin, että jotkut jotka ovat syntyneet hyökkääjiksi,

tietävät jo, että on hyvä tietää, missä kohta
muistia nollat ovat. Ja

nyt osoitamme esimerkin, missä rikomme A-S:n ja Iowan, jotka ovat kiihdytyskovona

yrityksen AI prosesseissa. Ja
nämä toimivat ainoastaan rekistereissä.

Juuri mainittiin, että tavallaan pidetään tuosta yksittäisestä osoituksesta muistiin,

mutta heti on olemassa toinenkin
temppu. Eli aina kun enklaavi on

keskeytetty, se säilöö senhetkiset rekisterinsä ja ajan johonkin muistilokeroonsa kehyksenä,

joten voimme keskeyttää ja verifioida sen tekevän oikein.

Ja sitten voimme ajaa tämän 0-tavu ennustajan tässä

SSA muistissa. Ja mitä löydämme; missä 0 on tai onko siellä nollia lainkaan.

En kuitenkaan halua mennä tarkemmin siihen, jos vastaus
on kyllä. Mutta mitä

itse asiassa teemme, kun löydämme nollan viimeisestä vaiheesta

ennen viimeistä lisäyskierrosta ja sitten huomaamme että nolla kaatuu ja muuttuu X:ksi

tai avaintavuksi, ja saamme tulokseksi salattua tekstiä. Me kuitenkin tiedämme

salatekstin tavun, ja voimme palata takaisin päin.

salatekstin tavun, ja voimme palata takaisin päin.

Tämä ketju toistetaan 16 kertaa, kunnes on löydetty jokainen 0,

ja meillä on käsissämme koko avain.

Ja ne jotka tietävät, jos on käsissä yksi avainkooste on käsissä myös koko avain.

Jos siis saat alkuperäisen avaimen, voit ajaa takaperin. Kuulostaa

monimutkaiselta, mutta se on hyvin nopea hyökkäys minkä voit seuratessa todeta.

Tässä on siis esimerkki tämän hyökkäyksen tekemisestä, ja kuten huomasitte muutamassa sekunnissa

ja noin 520 Asirin hyödyntämisellä, saamme koko KeIson.

Se on melko vaikuttavaa. Yksi keskeisimmistä

asioista on se, että muistiin ei itse asiassa laiteta mitään, mutta

toiminnassa SGX:n kanssa voit manipuloida sitä.

Haluankin tässä vaiheessa päättää tämän, olemme kuitenkin löytäneet useita muitakin haavoittuvuuksia.

Sekä tutkimus- että tuotantokoodissa, kuten Intelin tai

Microsoftin SDK:ssa.
Ja ne menevät läpi koko alueen käyttäen

vieraita kykyjä, joita on nähty muuallakin tutkimuksessa.

Mutta, on olemassa myös uudenlaisia mielenkiintoisia esittämiimme aspekteihin liittyviä haavoittuvuuksia.

Oli myös ongelmia kaikkien kutsuvälitysten kohdalla,

kun enklaavi kutsui ulkopuolellaan olevia osia.

Kutsuja joita käytetään emuloimaan järjestelmäkutsuja ja niin edelleen.
Ja jos palautat

tässä yhteydessä ollain tavalla väärän tuloksen, voidaan taas lipsahtaa rajojen ulkopuolelle. Ne myös

olivat erittäin, erittäin laajalle levinneitä. Ja lopuksi löysimme jotain tapauksia

liittyen paddingiin (kryptauksen toiminto). en taaskaan halua mennä yksityiskohtiin.

Olemme todenneet tässä asiassa, että voimme tehdä vertauksia oikeaan maailmaan.

On tärkeää pestä kätensä, eli on tärkeää huoltaa ja tiloittaa osoittimet

ja niin edelleen. Se on eräänlainen
poistumisviesti,

jolla kääntää ja ottaa yhteys turvallisesti.

Kyllä, kaikki kovo-ongelmat täytyy ratkaista, mutta koodin täytyy olla turvallista.

Enklaavien tapauksessa se tarkoittaa kunnollisia APIa ja APIen huoltoa. Tämä on itse asiassa erittäin

vaikea tehtävä, mielestäni

hyökkäyspinta-ala on suuri, erityisesti älykkään X:n

tapauksessa, missä voit keskeyttää jokaisen toimen ja niin edelleen. Mielestäni tutkimuksen

näkökulmasta, tarvitaan siis enemmän. Näkökulmasta jatkat jos haluat,

ehkä voimme oppia
jotain käyttäjästä analogiaan johon viittasin.

Luullakseni tätä tarvitaan, jotta ymmärretään mitä

enklaavin pitäisi tehdä verrattuna siihen mitä colonelin pitäisi
tehdä.

Ne ovat kuitenkin tärkeitä eroavaisuuksia, jotka tulisi ottaa huomioon. Joten luulisin,

kuten sanoit, kaikki koodimme
on avointa lähdekoodia.

Joten kaiken esitellyn voit löytää allaolevien Github -linkkien kautta

ja tietenkin voitte esittää kysymyksiä tämän esityksen katsomisen jälkeen.
Eli kiitoksia paljon.

No niin, olemme palanneet jälleen. Ja tässä kysymyksiä?

Ei vielä kysymyksiä....Voitte siis laittaa kysymyksiä tulemaan... Suljenpa nyt tämän

ja kysynkin nyt kysymyksiä teiltä. Miten päädyitte tähän aiheeseen ja miten tapasitte toisenne?

No se onkin melko mielenkiintoista. Ajattelen sen olevan

rakentuneen pitkällä aikavälillä vuosien saatossa.
Luulisin sen olevan tulosta

alkuperäisten suunnitelmiemme haavoittuvuuksista, Aloitin itse asiassa väitöskirjassani perusteiden keräämiseksi.

Emme itse asiassa nähneet koko kuvaa ennenkuin tapasimme

Davidin ja hänen kollegfansa Birminghamista Lontooseen.
Mukava konferenssi.

Ja sitten aloimme tehdä yhteistyötä ja toimia

systemaattisemmin. Aloitin tämän haavoittuvuuksien listaamisen

ja sen jälkeen teimme Davidin kanssa systemaattisemman analysoinnin.

Ja se oli se Pandoran lipas,

samoja virheitä toistaen. Sitten Fitzhugh, joka liittyi seuraamme hiljattain

Lontoossa, alkoi työskennellä kanssamme

matalan tason Sebu ominaisuuksien kanssa. Ja se itsessään on jo Pandoran lipas.

Sanoisin että erityisesti yksi opetus, kuten sanoimme, oli tuo tietty kuutonen, joka on erityisen monimutkainen.

Ja tuota kaikkea kompleksisuutta voidaan hyväksikäyttää, erityisesti

biodiversiteettiä. Se on kuin osa moniosaisuudesta,

missä avaat laatikon ja saat vastaukseksi yhä lisää kysymyksiä.

On mielestäni reilua sanoa, että tämä tutkimus ei ole

lopullinen vastaus aiheeseen, mutta se on yritys löytää järjestelmällinen tapa

tarkastella loputtomia perusteita.

Netin kautta on tullut kysymys. Onko muita olosuhteita missä

Mianus kirjoittaa rekistereihin, kuin juuri SGX?

Täytyy sanoa, etten myöskään ymmärrä kysymystä, mutta kokisin sen niin

että onko tulos taktinen häviö? Vankila riippuu siitä, että kun on muistin huollon

yhteydessä meitä syytetään sisällön muistiin

pakottamisesta.

Eli se on ehdottomasti hmmm.

Sanoisin kuitenkin että yksi opetuksista viimeisen viiden tutkimusvuoden aikana on,

että usein nämä asiat
yleistyvät kuutosen jälkeen
ja ainakin yleisesti,

oivallus SEBUsta, että oikeellisuus muistin käsittelyssä saavutetaan tavalla tai toisella,
ennemmin tai myöhemmin.

Mielestäni tuo pätee järjestelmien luomisessa, että jos jotenkin voi pakottaa

käyttöjärjestelmän kompleksisuuten
sovellusten osalta,

rekistereitten käyttö muistissa on pakollista. Jos teillä olisi jotain samankaltaista mitä

meillä on käyttöjärjestelmässä, Colonelissä, teillä olisi
potentiaalinen hyväksikäytön paikka.

Mutta ehkä David haluaa jotain käyttöjärjestelmistä myös.

Ei en oikeastaan.
Ajattelisin, että eräs asia mikä helpottaa SGX:n

kanssa on tiukka kontrolli, kuten mainitsit, keskeytysten ja muun
kanssa,

kun olette matkallanne enklaavin ulkopuolella. Voitte siis askeltaa käytännössä koko

enklaavin, kuten keskeyttämällä koko käyttöjärjestelmän.

Tarkoin toistettuna
oikeassa kohdassa joku toinen prosessi

on taipuvainen olemaan vaikeampi suunnittelultaan. Mutta kontekstissa, jossa

meidän täytyy tallentaa jotain turvaan, se on

rekisterit joista se päätyy muistiin,
joissain tilanteissa

vähemmän kontrolloidusti kuin esim. Asgeirssonin tapauksessa. On siis olemassa kysymys, entä muut CPU -arkkitehtuurit

kuin Intel, testasitteko niitä? Ehkä voin mennä hiukan tähän, mielenkiintoista.

Intelhän on suurin, sillä on suurin ohjelmistoalusta ja eniten ajossa olevia ympäristöjä.

Sitähän me voisimme tutkia.
Mutta tietenkin on olemassa muutakin,

kuten muutama vuosi sitten kehittämämme Sancho's.

Ja tietenkin silläkin on
samat aiheet. Eli aina tarvitaan

ohjelmistokerros jonka täytyy päästä enklaaviin.
Luullakseni

David aikaisemmassa työssään löysi ongelmakohtia TEE:sämme
Eli tämä ei ole ainoastaan

Intel-sidonnaisten projektien sotkun paikka. Mutta mitä me

varmasti huomasimme, on helpompaa ajatella kaikkia tapauksia yksinkertaisemmissa ympäristöissä

kuin viitosessa ja sitä helpommissa, kuin kompleksisemmaassa kuutosessa.

Joten nyt ei ole paljoa ympäristöjä vähemmille tempuille.

Heillä on siis etu ja haitta olla ensimmäisiä laajasti

levinneitä, mutta luulen että kun muutkin alkavat kasvaa

ja yksinkertaisemmat arkkitehtuurit yleistyvät,näemme että

on helpompi korjata väitettyjä ongelmia niissä. OK, mikä on

järkevä vaihtoehto TEElle vai onko sitä.

Meillä molemmilla on asiaan omat perspektiivimme, näin ajattelisin.

Kysymyksen vakiintuessa, tarvitsemmeko

vaihtoehtoja vai tarvitsemmeko systemaattisempia tapoja huoltaa

Australians? Se on mielestäni osavastaus tähän, että meidän ei tarvitse

heittää tätä hukkaan, vaikka sen kanssa on ongelmiakin.

Voimme myös miettiä miten ratkaista nuo ongelmat. Mutta sen ulkopuolella meillä on jännittävää

tutkimusta. OK, ehkä David myös haluaa sanoa hieman lisää esimerkiksi

ominaisuuksista, mutta se ei välttämättä ole niin erilaista
tähän verrattuna.

Silloin kun on high tech tukea kuten Cherry

Borjessonin tietokoneen osalla, joka itsesiallisesti yhdistää metadatan

metadatapisteisiin, kuten tilaustarkistuksia

silloin puhumiemme aiheiden saastutushyökkäyksiä voitaisiin saada

kiinni ilman itse ilman tukea. Mutta se on hyvin korkean tason idea. Ehkä David

jhaluaasanoa jotain. Kyllä, ajattelisin että vaihtoehtona TEE:lle,

haluat osittaa järjestelmäsi, mikä on mielestäni hyvä ajatus. Jza

Ja kaikki tekevät sitä nyt, miten online palveluita tehdään ja niin edelleen.

Nämä ovat järjestelmiä jotka ovat yleistyneet

matkapuhelimissa tai vaikkapa pankkikorttijärjestelmissä,

jotka ovat suojattu ympäristö yksinkertaisille toimille. Mutta

ongelmat alkavat, kun laitetaan paljon toiminnallisuuksia tähän ympäristöön.

Kuten näimme, luotettu koodipohja
tulee yhä monimutkaisemmaksi ja saadaan ympäristöstä perinteinen laatikko.

On todellinen kysymys, tarvitaanko vaihtoehto vaiko

parempi lähestymiskulma aiheeseen. Miten voitte, ositusohjelmistot? Ja kuten mainitsit

on asioita joita voi hoitaa arkkitehtuurilla.

Näin voidaan laajentaa arkkitehtuureita
ominaisuuksilla

ja sitten aloittaa komponenttien eristäminen.

Esimerkiksi, ohjelmistoprojektissa, sanotaanko Web-serverilläsi, sinä eristät stackin tai jotain vastaavaa. Ja

kiitokset katsojille salalisen salasanan huomaamisesta,
sehän tehdään vain näön tähden,

antaaksemme ihmisille jotain katseltavaa.

Mutta sehän ei ole perusteiltaan viallinen?
Tarkoitan että niitä on niin monia,

ettet voi sanoa niiden olevan perusteiltaan viallinen, mutta

erityisesti SGX:ää
ajatellen, koska signaali käyttää mobiilikolikoita

kryptovaluutta käyttää sitä, ja niin edelleen ja niin edelleen. Onko se perusteiltaan viallinen

vai haluatko mieluummin sanoa niin? Sehän riippuu perusteiltaan kunnossa olevan
määritelmästä.

Menneisyydessä olemme työskennelleet myös

asenteiden rikkomisen parissa, mutta ne on saatu korjattua ja on aika kaunis

ja hyvin tutkittu kokonaisuus jolla on myös lyhytaikaisia vaikutuksia tuotantoon.

Löydät siis haavoittuvuuden, toimittajan on tehtävä korjaus jota ei ole olemassa

tai siihen tulee väliaikainen
korjaus. Sitten myöhemmin

tarvitaan uusia prosesseja jotta saataisiin lopullinen korjaus ongelmaan

ja kuitenkin siihen
saadaan taas

väliaikaisia korjauksia. Jos esimerkiksi yhtiö kuten Signeul käyttää

niitä, et saa oletuksena turvallisuutta. Mutta täytyy ajatella

ohjelmistoja. niihin keskitytään tässä tapauksessa.
Täytyy ajatella

myös laitteistoja, mikropaikkauksia ja prosessoreita joissa täytyy huolehtia kaikista

tunnetuista haavoittuvuuksista. Ja silti täytyy aina kysyä, että entä

ne mahdollisuudet joita emme vielä tunne, missään turvallisessa järjestelmässä.

Ehkä David haluaa sanoa jotain viimeisimmästä työstään.

Hiukan mielenkiintoista.
Ajattelenpa, että mikä tahansa lähtökohtasi

tai minun vastaukseni tähän kysymykseen olisi, riippuu tietenkin
uhkamallista.

Jotkut käyttävät SGX:ää siirtääkseen luotetut asiat pilvipalvelun tuottajalle,

kuten RSS tai Signaler. Siirretään
siis kaikki nämä toiminnot

jollekin pilvitoimittajalle enklaaviin. Tällöin minun ei tarvitse

luottaa pilvitoimittajaan, koska myös fyysiseen turvallisuuteen on jotain.

luottaa pilvitoimittajaan, koska myös fyysiseen turvallisuuteen on jotain.
Vähän aikaa sitten paljastimme kuitenkin haavoittuvuuden,

joka osoittaa, että jos sinulla on fyysinen pääsy SGX:ään,

voit injektoida prosessorin pelaamalla voting rajapinnalla, joka on laitteistossa.

Siinä todellakin nähtiin, että pari johtoa emolevyn väylältä

jännitteen säätimeen. Saadaan aikaan jännitepiikki,

kuten
voitte tietääkin.

Sillä tavalla voidaan kääntää bittejä enklaavissa

ja näin tietenkin tehdä kaikenlaista

pahuutta, kuten injektoida,
jonka avulla taas voidaan saada avaimia, kaapata ohjaus, tai jotakin. Se siis riippuu

uhkamallista. En sanoisi niin, että ASX on täysin turha. Sekin

on parempi kuin ei mitään. Mutta
ehdottomasti, et voi olla

täysin turvassa jos jollain on fyysinen pääsy palvelimellesi.

Nyt minun täytyy lopettaa keskustelu, pahus sentään. Ja kysyisin kaikki kysymykset

jotka sain. Mutta hyvin lyhyt
vastaus, kiitos. Mikä tuo juttu on tuon

salasanan kanssa tuolla taustalla?
Minähän selitin sen, se on vaan puhdas vitsi.

Sanon sen vielä kerran, koska jotkut näyttävät ottaneen sen vakavasti.
Se on

vain tilan täytteeksi.
Laitoin sen vaan sinne sen takia. Se ei muutoin olekaan kokonaan sieltä luettavissa, onneksi.

Minun täytyy varmasti ottaa ja avata David Oswaldin kirja.

Kiitokset hyvätä keskustelusta ja nyt siirrytäänkin seuraavaan

esitykseen.

[Translated by Kari Kananoja (ITKST56 course assignment at JYU.FI)] 2023