Zenbleed: kuidas protsessori jõudluse otsimine võib teie paroolid ohtu seada

Zenbleed: kuidas protsessori jõudluse otsimine võib teie paroolid ohtu seada

Zenbleed: kuidas CPU jõudluse otsimine võib teie paroolid ohtu seada PlatoBlockchain Data Intelligence. Vertikaalne otsing. Ai.

Kas mäletate Heartbleedi?

See oli viga, mis 2014. aastal lisas sufiksi - verejooks haavatavust, et andmete lekkimine juhuslikult viisil, mida ei ründaja ega ohver ei saa usaldusväärselt kontrollida.

Teisisõnu, kelm ei saa täppisrünnakuks kasutada bleed-stiilis viga, näiteks „Leia paroolivarjufail /etc kataloogi ja laadige see mulle üles” või „Otsi mälus tagurpidi kuni 16 järjestikuse ASCII-numbri esimese käivitamiseni; see on krediitkaardi number, nii et salvestage see hilisemaks.

Näiteks Heartbleedis võite petta paigatamata serverit, et ta saadaks kirja, mis pidi olema maksimaalselt 16 baiti pikk, kuid sisaldas ekslikult kuni umbes 64,000 XNUMX lõppu kleebitud lisabaiti.

Te ei saanud valida, mis on nendes 64,000 XNUMX rüüstatud baidis; sa lihtsalt said kõik, mis juhtus kõrvuti tõelise sõnumiga, mille pidid saama.

Mõnikord võite saada tükke kõigist nullidest või tundmatutest krüptitud andmetest, mille jaoks teil polnud dekrüpteerimisvõtit...

…aga aeg-ajalt saate veebilehe selgeteksti fragmente, mille eelmine külastaja alla laadis, või osa e-kirjast, mille keegi teine ​​just saatis, või isegi mäluplokke, milles on serveri enda privaatsed krüptograafilised võtmed.

Rohked nõelad lõpututes heinakuhjades

Ründajad kasutavad tavaliselt ära verejooksupõhiseid vigu, käivitades need ikka ja jälle automaatselt, kogudes tohutu hunniku volitamata andmeid ja seejärel neid hiljem oma vabal ajal läbi kammides.

Nõelu on heinakuhjadest üllatavalt lihtne välja tõmmata, kui (a) saate otsingu automatiseerida, kasutades tarkvara, mis teeb teie eest raske töö ära, (b) te ei vaja kohe vastuseid ja (c) teil on palju ja palju heinakuhju, nii et võite endale lubada, et jätate paljud või isegi enamiku nõelte vahele ja saate ikkagi märkimisväärse varu.

Muud verejooksu nimega vead hõlmavad Rambled, mis kutsus tahtlikult esile ajutisi mäluvigu, et arvata, mis on salvestatud RAM-i kiibi lähedal asuvatesse osadesse, ja Optionsbleed, kus saite veebiserverilt ikka ja jälle küsida, milliseid HTTP-suvandeid see toetab, kuni see saatis teile kogemata vastuse, milles on kellegi teise andmed.

Analoogiliselt on bleed-stiilis bug natuke nagu tagasihoidlik loterii, millel ei ole garanteeritud mega-jackpoti auhindu, kuid kus saate alatu võimaluse osta 1,000,000 XNUMX XNUMX piletit ühe hinnaga.

Noh, kuulus Google'i veakütt Tavis Ormandy on just seda teinud teatas uuest veast seda tüüpi, mida ta on dubleeritud Zenbleed, sest viga kehtib AMD uusima kohta Zen 2 suure jõudlusega protsessorite valik.

Kahjuks saate peaaegu iga arvuti protsessi või lõime viga ära kasutada ja pseudojuhuslikult andmeid peaaegu kõikjalt mälust kustutada.

Näiteks külaliste virtuaalmasinas (VM) töötav programm, mis peaks olema ülejäänud süsteemist isoleeritud, võib saada andmeid teistelt sama VM-i kasutajatelt või teistelt sama VM-i kasutajatelt. arvutist või hostprogrammist, mis peaks VM-e juhtima, või isegi hosti operatsioonisüsteemi enda tuumast.

Ormandy suutis looma kontseptsiooni tõestuskood, mis lekitas umbes 30,000 16 baiti teiste inimeste andmeid sekundis protsessori tuuma kohta, XNUMX baiti korraga.

See ei pruugi tunduda palju, kuid 30 kB/s on piisav, et päeva jooksul paljastada ilmatu 3 GB, kusjuures võib-olla ilmuvad andmed, millele pääseb juurde regulaarselt (sh paroolid, autentimismärgid ja muud andmed, mida tuleks hoida saladuses). korduvalt.

Ja kuna andmed avaldatakse 16-baidiste tükkidena, leiavad ründajad püütud teabest tõenäoliselt palju äratuntavaid fragmente, mis aitavad neil heinakuhju sõeluda ja sorteerida ning nõeltele keskenduda.

Esituse hind

Me ei püüa siin Zenbleedi viga selgitada (vt Tavis Ormandy oma enda artikkel üksikasjade jaoks), kuid keskendume põhjusele, miks viga üldse ilmnes.

Nagu te ilmselt arvasite, arvestades, et oleme juba viidanud protsessidele, lõimedele, tuumadele ja mäluhaldusele, on see viga sisemiste "funktsioonide" kõrvalmõju, mida kaasaegsed protsessorid kaasavad, et jõudlust nii palju kui võimalik parandada. , sealhulgas kena, kuid veaohtlik nipp, mida kaubanduses tuntakse kui spekulatiivne hukkamine.

Lahedalt öeldes on spekulatiivse täitmise mõte selles, et kui protsessori tuum muidu seisaks jõude ja ootaks võib-olla teada saada, kas see peaks katki minema. THEN või ELSE Kui-siis-muidu otsuse tee teie programmis või riistvara juurdepääsukontrolli ootamine, et teha kindlaks, kas konkreetsele mäluaadressile salvestatud andmeväärtust on tõesti lubatud kasutada või mitte...

…siis tasub niikuinii edasi künda ja ette arvutada (see on “spekulatiivse hukkamise” osa), kui vastus peaks kasuks tulema.

Kui spekulatiivne vastus osutub tarbetuks (kuna see õnnestus THEN tulemus, kui kood läks alla ELSE asemel tee) või jääb praeguse protsessi piiridest välja (ebaõnnestunud juurdepääsukontrolli korral), saab selle lihtsalt ära visata.

Võite mõelda spekulatiivsele hukkamisele nagu viktoriini saatejuht, kes piilub vastust kaardi allosas, kui nad praegust küsimust esitavad, eeldades, et võistleja proovib vastata ja ta peab vastusele otse viidata. ära.

Kuid mõnes viktoriini saates võib võistleja öelda "Läbi", jättes küsimuse vahele, et hiljem selle juurde tagasi tulla.

Kui see juhtub, peab peremees kasutamata vastuse oma meelest välja panema ja jätkama järgmise küsimusega, järgmisega ja nii edasi.

Kui aga „söödu“ küsimus tuleb uuesti ette, siis kui palju mõjutab see, et nad teavad vastust ette, seda, kuidas nad seda teist korda küsivad?

Mis saab siis, kui nad loevad küsimust tahtmatult teisiti või kasutavad teistsugust hääletooni, mis võib anda võistlejale tahtmatu vihje?

Lõppude lõpuks on ainus tõeline viis millegi täielikult "unustada" see, kui te pole seda kunagi teadnud.

Häda vektoritega

Ormandy Zenbleedi veas, mis on nüüd ametlikult tuntud kui CVE-2023-20593, tekib probleem siis, kui AMD Zen 2 protsessor täidab olemasolev spetsiaalne käsk määrata mitme nn. vektorregistrid samal ajal nulli.

Vektorregistreid kasutatakse andmete salvestamiseks, mida kasutavad spetsiaalsed suure jõudlusega numbri- ja andmetöötluskäsud ning enamikes kaasaegsetes Inteli ja AMD protsessorites on need 256 bitti laiad, erinevalt traditsioonilisel programmeerimisel kasutatavatest protsessori üldotstarbelistest registritest 64 bitist. .

Neid spetsiaalseid vektorregistreid saab tavaliselt kasutada kas 256 bitti (32 baiti) korraga või ainult 128 bitti (16 baiti) korraga.

Tegelikult on ajaloolistel põhjustel tänapäeva CPU-del kaks täiesti erinevat vektor-stiilis masinkoodi käskude komplekti: uuem hunnik, mida tuntakse kui AVX (täpsemad vektorlaiendid), mis võib töötada 128 või 256 bitiga, ja vanema, vähem võimsa käskude rühmaga SSE (SIMD laienduste voogesitamine, kus SIMD omakorda tähistab ühe käsu/mitme andmed), mis saab korraga töötada ainult 128 bitiga.

Ärritav on see, et kui kasutate mõnda uut tüüpi AVX-koodi, siis mõnda vana stiili SSE-koodi ja seejärel veel mõnda AVX-koodi, ajavad keskel olevad SSE-juhised sassi uute 128-bitiste AVX-registrite ülemised 256 bitti, kuigi SSE juhised teevad vähemalt paberil oma arvutusi ainult alumisel 128 bitil.

Nii salvestab protsessor vaikselt AVX-registrite ülemised 128 bitti enne tagurpidi ühilduvasse SSE-režiimi lülitumist ja taastab need salvestatud väärtused, kui hakkate järgmisel korral AVX-i juhiseid kasutama, vältides nii vana ja uue vektorkoodi segamisel tekkivaid ootamatuid kõrvalmõjusid. .

Kuid see salvestamise ja taastamise protsess kahjustab jõudlust, mida mõlemad Inteli ja AMD-d programmeerimisjuhendid hoiatavad teid tugevalt.

AMD ütleb:

Kui [128-bitise laiusega] YMM-i registrite ülemised 256 bitti sisaldavad nullist erinevaid andmeid, on SSE ja AVX-i käskude segamise eest ette nähtud märkimisväärne karistus.

Kummaski suunas üleminek põhjustab mikrovea väljavalgumise või kõigi kuueteistkümne YMM-i registri ülemise 128 biti täitumise.

Selle vea märku andmiseks ja käsitlemiseks määratakse ligikaudu 100 tsükli trahvi.

Ja Intel ütleb midagi sarnast:

Riistvara salvestab [128-bitise laiusega] YMM-i registrite ülemise 256 biti sisu AVX-lt SSE-le üleminekul ja taastab need väärtused tagasi siirdumisel […]

Nii salvestamise kui ka taastamise toimingud põhjustavad trahvi, mis ulatub iga toimingu kohta mitmekümne kellatsüklini.

Päeva päästmiseks on olemas spetsiaalne vektorjuhis VZEROUPPER mis nullib iga vektorregistri ülemised 128 bitti ühe korraga.

Helistades VZEROUPPER, isegi kui teie enda kood seda tegelikult ei vaja, annate protsessorile märku, et te ei hooli enam nende 128-bitiste registrite ülemisest 256 bitist, nii et neid pole vaja salvestada, kui tuleb vana kooli SSE käsk. järgmisena.

See aitab teie koodi kiirendada või vähemalt takistab teil teiste oma koodi aeglustamast.

Ja kui see kõlab natuke jaburana…

…no on küll.

See on protsessoritaseme häkkimine, kui soovite, et tagada, et te ei vähenda jõudlust, proovides seda parandada.

Kuhu tuleb CVE-2023-20593?

Kogu see jõudluse fikseerimine viis Ormandy Zenbleedi andmelekke auku, kuna:

  • AVX-koodi kasutatakse väga sageli mittematemaatilistel eesmärkidel, näiteks tekstiga töötamiseks. Näiteks populaarne Linuxi programmeerimise raamatukogu glibc kasutab funktsiooni kiirendamiseks AVX juhiseid ja registreid strlen() seda kasutatakse tekstistringide pikkuse leidmiseks keeles C. (Lõdvalt öeldes, strlen() AVX-koodi kasutamine võimaldab teil otsida korraga läbi 16 baiti stringi, otsides nullbaiti, mis tähistab selle lõppu, selle asemel, et kasutada tavalist tsüklit, mis kontrollib baithaaval.)
  • AMD Zen 2 protsessoreid ei saa usaldusväärselt tagasi võtta VZEROUPPER kui spekulatiivne täitmiskoodi tee ebaõnnestub. 128-vektorilise registri 256 ülemise biti nullimisel, kuna protsessor arvas valesti ja VZEROUPPER operatsioon tuleb ümber pöörata, mõnikord jõuab register 128 bitti (16 baiti), mis on "taastatud" kellegi teise AVX-koodist, mitte varem tegelikult olnud andmete asemel.

Päriselus tundub, et programmeerijad kasutavad seda harva VZEROUPPER ümberpööramist vajavatel viisidel või muidu võidi see viga avastada aastaid tagasi, võib-olla isegi AMD enda arenduse ja testimise käigus.

Kuid hoolikalt katsetades sai Ormandy välja, kuidas luua AVX-koodisilmuseid, mis mitte ainult ei käivitanud korduvalt spekulatiivset käivitamist. VZEROUPPER käsk, kuid sundis ka seda käsku regulaarselt tagasi kerima ja AVX-registrid nullimata.

Kahjuks kasutavad paljud teised tavapärased programmid suurel määral AVX-i juhiseid, isegi kui need ei ole sellised rakendused, nagu mängud, kujutise renderdamise tööriistad, paroolimurdjad või krüptokaevarid, mille jaoks arvate, et vajate kiiret vektor-stiilis koodi.

Teie operatsioonisüsteem, meiliklient, veebibrauser, veebiserver, lähtekoodiredaktor, terminaliaken – peaaegu iga programm, mida rutiinselt kasutate – kasutab peaaegu kindlasti jõudluse parandamiseks õiglast osa AVX-koodist.

Nii et isegi väga tüüpilistes tingimustes sattus Ormandy mõnikord teiste programmide andmete kummituslike jäänustega, mis segati tema enda AVX-andmetesse, mida ta suutis tuvastada ja jälgida.

Lõppude lõpuks, kui teate, mis peaks olema AVX-registrites pärast a VZEROUPPER toiming tühistatakse, on lihtne märgata, kui nendes registrites olevad väärtused viltu lähevad.

Ormandy enda sõnadega:

[B]põhitoimingud nagu strlen(), memcpy() ja strcmp() [otsa tekstistringi pikkus, kopeeri mälu, võrrelge tekstistringe] kasutab vektorregistreid – nii saame tõhusalt luurata neid toiminguid, mis toimuvad kõikjal süsteemis!

Pole tähtis, kas need toimuvad teistes virtuaalmasinates, liivakastides, konteinerites, protsessides või milles iganes.

Nagu varem mainisime, kui teil on iga protsessori tuuma kohta 3 GB struktureerimata, pseudojuhuslikult valitud kummitusandmeid, ei pruugi te mitme miljoni dollari suuruse jackpoti loterii ekvivalenti saavutada.

Kuid olete peaaegu kindel, et võidate tuhandete 1000-dollariliste auhindadega samaväärseid auhindu, ilma et peaksite riskivalt oma nina teiste inimeste protsessidesse ja mälulehtedesse torkama, nagu seda peab tegema traditsiooniline RAM-i nuhkimise pahavara.

Mida teha?

CVE-2023-20593 avalikustati vastutustundlikult ja AMD on juba loonud mikrokoodi plaaster vea leevendamiseks.

Kui teil on Zen 2 perekonna protsessor ja olete selle vea pärast mures, rääkige oma emaplaadi müüjaga, et saada lisateavet asjakohaste paranduste hankimise ja rakendamise kohta.

Operatsioonisüsteemidel tarkvaratööriistadega, mis toetavad nn MSR-ide kohandamist (mudelipõhised registrid) teie protsessoris, mis juhib selle madalat konfiguratsiooni, on dokumenteerimata lipp (bitt 9), mille saate määrata halvasti dokumenteeritud mudeliregistris (MSR 0xC0011029), mis ilmselt lülitab välja vea põhjustava käitumise.

MSR 0xC0011029 on viidatud Linuxi kerneli meililoendis arhiiv kui DE_CFG register, ilmselt lühike dekodeerida konfiguratsiooni, ja teisi selle registri tuntud bitte kasutatakse spekulatiivse täitmise muude aspektide reguleerimiseks.

Seetõttu oletame seda DE_CFG[9], mis on lühend sõnadest MSR 9xC0 bit 0011029, otsustab, kas lubada keeruliste kõrvalmõjudega juhiseid, nagu VZEROUPPER üldse spekulatiivselt järele proovida.

Ilmselgelt, kui te ei lase protsessoril kunagi vektorregistreid nullida, välja arvatud juhul, kui te juba teate kindlalt, et te ei pea kunagi neid registreid nullist eemaldama ja muudatusi tagasi võtma, ei saa seda viga kunagi käivitada.

Asjaolu, et seda viga seni ei märgatud, viitab sellele, et VZEROUPPER seda ei juhtu väga sageli ja seetõttu ei avalda see madala taseme häkkimine/parandus tõenäoliselt jõudlusele märgatavat mõju.

Ormandy artikkel sisaldab kirjeldust selle kohta, kuidas oma Zen 2 protsessoris vastavat MSR-bitti ümber seadistada Linuxis ja FreeBSD-s.

(Sa näed DE_CFG[9] kirjeldatakse kui kanatükk, kasutatavate konfiguratsiooniseadete kõnepruuk on pöörama maha funktsioon, mida te kardate.)

OpenBSD, kuuleme, on sundiv DE_CFG[9] automaatselt sisse lülitatud kõigis Zen 2 protsessorites, vähendades seega selle vea vaikimisi, otsides jõudlusele turvalisust; peal Linux ja muud BSD-d, saate seda teha käsurea tööriistadega (vajalik juur), näiteks wrmsr ja cpucontrol.

moon kasutajad saavad lõõgastuda, sest meile teadaolevalt on kõigil mitte-ARM-i Mac-arvutitel Inteli kiibid, mitte AMD omad, ja Inteli protsessorid pole teadaolevalt selle konkreetse vea suhtes haavatavad.

Windows kasutajad peavad võib-olla kasutama mitteametlikke kerneli draiverite häkkimisi (vältige neid, kui te tõesti ei tea, mida teete, kuna režiimis "luba kõik vanad draiverid" käivitamine võib põhjustada turvariske) või installima ametliku WinDbg siluri, lubage kohalik kerneli silumine ja kasutage WinDbg-skripti vastava MSR-i kohandamiseks.

(Tunnistame, et pole ühtegi neist leevendustest proovinud, sest meil pole hetkel käepärast AMD-põhist arvutit; andke meile teada, kuidas teil läheb, kui saate!)


Ajatempel:

Veel alates Alasti turvalisus