[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