[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