APIC/EPIC! Inteli kiibid lekivad saladusi, isegi tuum ei peaks nägema ...

Siin on selle nädala BWAIN, meie naljakas termin a Muljetavaldava nimega viga.

BWAIN on tunnustus, mille jagame välja, kui uus küberturvalisuse viga ei osutu mitte ainult huvitavaks ja oluliseks, vaid ilmub ka oma logo, domeeninime ja veebisaidiga.

See on dubleeritud ÆPIC leke, sõnamäng sõnade kohta APIC ja EPIC.

Esimene on lühend Täiustatud programmeeritav katkestuskontroller, ja viimane on lihtsalt sõna "eepiline", nagu on hiiglane, suur, äärmuslik, mega, hiigelsuur.

Æ-tähte pole inglise keeles kirjalikus keeles kasutatud alates Saksi ajast. Selle nimi on æsc, hääldatakse saar (nagu puus) ja see esindab suures osas A-heli tänapäevases sõnas ASH. Kuid me eeldame, et peaksite selle sõna hääldama ÆPIC siin kas "APIC-kaldkriips-EPIC" või kui "ah!-eh?-PIC".

Mis see kõik on?

Kõik see tõstatab viis põnevat küsimust:

• Mis on APIC, ja miks mul seda vaja on?
• Kuidas teil on selliseid andmeid isegi tuum ei saa piiluda?
• Mis põhjustab selle eepilise ebaõnnestumise APIC-s?
• Kas ÆPIC leke mõjuta mind?
• Mida teha sellest?

Mis on APIC?

Kerime tagasi aastasse 1981, mil IBM PC esmakordselt ilmus.

Arvutil oli kiip nimega the Intel 8259A programmeeritav katkestuskontrollervõi PIC. (Hilisematel mudelitel, alates PC AT-st, oli kaks kokku aheldatud PIC-i, et toetada rohkem katkestusi.)

PIC-i eesmärk oli sõna otseses mõttes katkestada arvuti keskprotsessoris (CPU) töötav programm, kui toimus midagi ajakriitilist, mis vajas kohe tähelepanu.

Need riistvaralised katkestused hõlmasid selliseid sündmusi nagu: klaviatuur saab klahvivajutuse; jadaport, mis võtab vastu märgi; ja korduv riistvarataimer tiksub.

Ilma seda tüüpi riistvarakatkestussüsteemita peaks operatsioonisüsteem olema täis funktsioonikutseid, et kontrollida regulaarselt sissetulevaid klahvivajutusi, mis oleks protsessori võimsuse raiskamine, kui keegi ei kirjuta, kuid ei reageeriks. piisavalt, kui nad seda tegid.

Nagu võite ette kujutada, järgnes PIC-ile peagi täiendatud kiip nimega the APIC, edasijõudnud omamoodi CPU-sse sisseehitatud PIC.

Tänapäeval pakuvad APIC-d palju enamat kui lihtsalt tagasisidet klaviatuurilt, jadapordilt ja süsteemitaimerilt.

APIC-sündmused käivitavad (ja annavad nende kohta reaalajas andmeid) sündmused, nagu ülekuumenemine, ning võimaldavad tänapäevaste mitmetuumaliste protsessorite erinevate tuumade vahel riistvaralist interaktsiooni.

Ja tänapäevaseid Inteli kiipe, kui võib väga lihtsustada, saab üldiselt konfigureerida töötama kahel erineval viisil, nn. xAPIC režiim ja x2APIC režiim.

Siin xAPIC on "pärand" viis katkestuskontrollerist andmete eraldamiseks ja x2APIC on moodsam viis.

Veelgi enam lihtsustades tugineb xAPIC sellele, mida nimetatakse MMIO, lühike mälukaardistatud sisend/väljund, andmete lugemiseks APIC-st, kui see registreerib huvipakkuva sündmuse.

MMIO-režiimis saate teada, mis APIC-sündmuse käivitas, lugedes konkreetsest mälupiirkonnast (RAM), mis peegeldab APIC-kiibi sisend-/väljundregistreid.

Need xAPIC-andmed on kaardistatud 4096-baidisesse mäluplokki kuskil arvuti füüsilises RAM-is.

See lihtsustab andmetele juurdepääsu, kuid nõuab APIC-kiibi ja süsteemimälu vahelist tüütut, keerulist (ja, nagu näeme, potentsiaalselt ohtlikku) koostoimet.

Seevastu x2APIC nõuab teilt seda loe APIC andmed otse välja kiibist endast, kasutades nn Mudelipõhised registrid (MSR-id).

Inteli sõnul vältides protsessi MMIO osa "pakkub oluliselt suuremat protsessori adresseeritavust ja mõningaid täiustusi katkestuste edastamisel."

Eelkõige tähendab APIC-andmete eraldamine otse kiibisisestest registritest, et toetatud andmete koguhulk ja samaaegselt hallatavate CPU-tuumade maksimaalne arv ei ole piiratud MMIO-režiimis saadaoleva 4096 baidiga.

Kuidas saab teil olla andmeid, mida isegi kernel ei näe?

Tõenäoliselt olete juba arvanud, et xAPIC-režiimi kasutamisel MMIO-mälupiirkonda jõudvaid andmeid ei hallata alati nii hoolikalt, kui peaks...

…ja seega on selle probleemi keskmes mingisugune "andmete leke" sellesse MMIO piirkonda.

Aga arvestades seda, et sa vajavad juba süsteemiadministraatori tasemel volitusi MMIO-andmete lugemiseks ja seetõttu saate peaaegu kindlasti kõik andmed mällu ...

...miks tähendab see, et teiste inimeste andmed kuvatakse kogemata APIC MMIO andmealal eepiline lekkida?

See võib teatud tüüpi andmete varastamise või RAM-i kraapimise rünnakuid praktikas pisut lihtsamaks muuta, kuid kindlasti ei annaks see teile rohkem mälu nuhkimise võimet, mis teil teoreetiliselt juba oli?

Kahjuks ei vasta see eeldus tõele, kui mis tahes süsteemis olev tarkvara kasutab Inteli SGX-i, lühendatult Tarkvarakaitse laiendused.

---

LISATEAVE SGX-I KOHTA

---

SGX-i toetavad paljud hiljutised Inteli protsessorid ja see annab operatsioonisüsteemi tuumale võimaluse "sulgeda" tükk koodi ja andmeid RAM-i füüsilisse plokki, et moodustada enklaav.

See paneb selle vähemalt ajutiselt käituma sarnaselt mobiiltelefonide spetsiaalsetele turvakiipidele, mida kasutatakse saladuste, näiteks dekrüpteerimisvõtmete, salvestamiseks.

Kui enklaavi SGX-lukk on seadistatud, saab selle RAM-i sisu lugeda ja kirjutada ainult suletud mälualal töötav programmikood.

Selle tulemusena on pärast enklaavi aktiveerimist tehtavate arvutuste sisemised üksikasjad nähtamatud ühelegi teisele süsteemi koodile, lõimele, protsessile või kasutajale.

Kaasa arvatud kernel ise.

On olemas viis enklaavi suletud koodi väljakutsumiseks ja võimalike arvutuste väljundi tagastamiseks, kuid koodi ei ole võimalik taastada, selle järele luurata või siluda. sellega seotud andmed töötamise ajal.

Enklaav muutub tõhusalt mustaks kastiks, kuhu saate sisestada sisendeid, näiteks privaatvõtmega allkirjastatavaid andmeid, ja eraldada väljundeid, näiteks genereeritud digitaalallkirja, kuid kust te ei saa krüptovõtmeid välja pilgutada. kasutatakse allkirjastamise protsessis.

Nagu võite ette kujutada, kui andmed, mis peaksid olema suletud SGX-enklaavis, peaksid kunagi kogemata dubleerima MMIO RAM-i, mida kasutatakse APIC-andmete "peegeldamiseks", kui kasutate xAPIC-i "mälukaardistatud" režiimi...

… mis rikuks SGX-i turvalisust, mis ütleb, et pärast loomist ei tohi SGX-enklaavist kunagi välja tulla andmeid, välja arvatud juhul, kui need on teadlikult eksporditud koodiga, mis töötab juba enklaavis endas.

Mis põhjustab selle eepilise rikke APIC-s?

Teadlased taga ÆPIC Lekkiv paber avastas, et korraldades APIC-andmete lugemise kavala ja ebatavalise mälupöördusjärjestuse kaudu ...

...nad võivad petta protsessorit, et täitma APIC MMIO ruumi mitte ainult APIC-lt endalt saadud andmetega, vaid ka andmetega, mida protsessor just hiljuti mõnel muul eesmärgil kasutas.

Selline käitumine on kõrvalmõju tõsiasjale, et kuigi APIC MMIO mäluleht on 4096 baiti suur, ei tooda APIC-kiip xAPIC-režiimis tegelikult 4096 baiti andmeid ja protsessor ei neutraliseeri alati õigesti. MMIO piirkonna kasutamata osad, täites selle esmalt nullidega.

Selle asemel kirjutati välja protsessori vahemällu jäänud vanad andmed koos APIC-kiibilt endalt saadud uute andmetega.

Nagu teadlased ütlesid, taandub viga sellele, mida nimetatakse an initsialiseerimata mälu lugemine, kus kasutate kogemata uuesti kellegi teise RAM-is allesjäänud andmeid, kuna ei nemad ega teie ei tühjendanud seda esmalt varasematest saladustest.

Kas ÆPIC-leke mõjutab mind?

Mõjutatud kiipide täieliku loendi vaatamiseks vt Inteli enda nõuanded.

Niipalju kui saame öelda, on see tõenäoliselt mõjutatud, kui teil on 10. või 11. põlvkonna Inteli protsessor.

Kuid kui teil on uhiuus 12. põlvkonna protsessor (kirjutamise ajal uusim), siis tundub, et see mõjutab ainult serveriklassi kiipe.

Irooniline on see, et 12. põlvkonna sülearvutikiipide puhul on Intel SGX-i kasutamisest loobunud, nii et see viga ei kehti, kuna on võimatu lekkida "suletud" SGX enklaave.

Muidugi, isegi potentsiaalselt haavatava kiibi puhul, kui te ei tugine ühelegi SGX-i kasutavale tarkvarale, ei kehti ka viga.

Ja viga, dubleeritud CVE-2022-21233, saab kasutada ainult ründaja, kellel on juba teie arvutile kohalik administraatoritaseme (juurjuurdepääs).

Tavakasutajad ei pääse APIC MMIO andmeplokile juurde ja seetõttu ei saa seal üldse midagi piiluda, rääkimata salajastest andmetest, mis võisid SGX enklaavist välja lekkida.

Niisiis, külaliste virtuaalsed masinad (VM-id), mis töötavad hosti operatsioonisüsteemi juhtimise all hüperviisoris, nagu HyperV, VMWare või VirtualBox, ei saa peaaegu kindlasti seda trikki kasutada teiste külaliste või hosti enda saladuste röövimiseks.

Selle põhjuseks on asjaolu, et külalis-VM-id ei pääse üldiselt hostprotsessori tegelikule APIC-skeemile; Selle asemel saab iga külaline oma simuleeritud APIC-i, mis on selle virtuaalse masina jaoks ainulaadne.

Mida teha?

Ärge paanitsege.

Süle- või lauaarvuti puhul ei pruugi te ohtu sattuda, kuna teil on vanem (või õnneks täiesti uus!) arvuti või seetõttu, et te ei looda niikuinii SGX-ile.

Ja isegi kui olete riskantne, on kõigil, kes satuvad teie sülearvutisse administraatorina/juurena, tõenäoliselt piisavalt jõudu, et teile juba praegu probleeme tekitada.

Kui teil on haavatavad serverid ja kasutate oma tööturbe osana SGX-i, vaadake Inteli turvanõuannet INTEL-SA-00657 kaitse ja leevendamise teabe saamiseks.

Selle kirjutanud teadlaste sõnul "Intel [on] probleemi lahendamiseks välja andnud mikrokoodi ja SGX tarkvaraarenduskomplekti värskendused."

Tundub, et Linuxi kerneli meeskond töötab praegu ka paiga kallal, mis võimaldab teil oma süsteemi konfigureerida nii, et see kasutaks alati x2APIC-i (mis, nagu te varasemast mäletate, ei edasta APIC-andmeid ühismälu kaudu). ja väldib graatsiliselt süsteemi sunnitud tagasi xAPIC-režiimi pärast käivitamist.

---