Hertzbleed Attack - újabb Intel/AMD CPU sebezhetőség

Bug

A Hertzbleed egy, a side-channel támadások új családja. Technikai bemutatójára a 31st USENIX Security Symposium rendezvényen kerül majd sor (Boston, 2022. augusztus 10-12.) az alábbi címmel: Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86. A technikai dokumentáció elérhető itt.

   

A sebezhetőség weboldal itt.

Tanult Kollégám hozzászólásából bizonyos fokú maradiság világlik ki. Közismert ugyanis, hogy a modern processzorokban az AX regiszter már kellően rugalmas ahhoz, hogy képes legyen tömörítés nélkül is befogadni ekkora számokat.

Követni kellene a technika fejlődését és csak aztán kötözködni.

Science for fun...

( hajbazer v | 2022. 06. 17., p – 15:03 )

Kriptográfiai implementációk felkészülnek az értelmetlen belassításukra ... 3 ... 2 ... 1 ... a biztonságunk™ érdekében™.

Egyszerűbb lenne, ha az Intel/AMD kiírná, hogy dátumra pontosan mikor kell újravásárolni a processzoraikat és kidobni a régit, máskülönben csődbe mennek és nem lesz több x86-alapú számítógép nem lesz meg a százalék és az új yacht a befektetőknek.

Az a baj, hogy ezekkel a hardveres procisérülékenységekkel annyira felpörögtek, hogy teljesen értelmetlen új procit venni csak azért, x hónap múlva találnak a legújabban is. Ez egy teljesen szélmalomharc lett. Még a kriptográfia se elég ide, mert a kriptoalgoritmus is magán a sérülékeny procin fut. Yach a befeketetőknek az mindig is lesz, akkor is, ha nem veszel újat, akkor meg azt fogják csinálni, hogy megemelik az árát, és ha ritkábban is veszel, az annyival drágább lesz, nekik a profitjuk sose fog csorbulni. Ezt nem érti állombácsi se, hogy az adókkal, áfákkal, vámokkal nem a tőkéseket, gyártókat bünteti, hanem a kisembert szopatják meg, mert a sor végén ők fizetik ki az egész cechet.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Sőt, mondhatnám, hogy ez egy kifejezetten "újprocesszor" betegség. A régiek turbo boost-ja - már amelyiknek volt egyáltalán - annyira lassan reagált, hogy nem lehetett kihasználni ilyen módon. Illetve nem túrbózta túl a processzort, hogy utána vissza kelljen throttlingolnia.

Ugyan nem rágtam még végig a 19 oldalt, de eddig az jött nekem le, hogy a processzor túlfogyasztás és túlmelegedés elleni védelme miatt tud adatfüggő módon ingadozni a frekvencia és így válnak a papíron konstans futási idejű kripto algoritmusok adatfüggően eltérő futási idejűvé.

Ez az egész attól van, hogy a gyártástechnológiai fejlődés már nem járt órajel növekedéssel, ezért a processzorgyártók jobb híján elkezdték gyárilag túlhúzni a processzort, hogy azt a kevéske tartalékot, amit korábban az overclockerek szoktak kisajtolni, az most gyárilag kihozzák belőle. Csak ezzel az egekbe felugrik a fogyasztás és hőtermelés, amire sem alaplapi áramellátást, sem hűtést nem akarják a gyártók méretezni, mert akkor kb vízhűtés kéne minden notebookba is. Ezért az van, hogy nagyon rövid ideig szénné húzza magát a processzor, aztán ha a terhelés nem szűnik meg, akkor elég hamar visszaveszi az órajelet, mert lokálisan túlmelegszik valami, vagy a feszültségstabilizátor nem bírja tartani az áramellátást. Az utóbbi pár generációban azon versenyzett az Intel meg az AMD, hogy ki tud gyorsabban és finomabb felbontással reagáló boost-ot kiépíteni. (Az alaplapgyártók, meg inofficially kiiktatták az időlimitet a boost-ra, aztán jöttek a meglepik, hogy a 95W-os TDP-jű processzor miért eszik 225W-ot...) A lényeg, hogy most már elég időbeli felbontása lett a boost-nak ahhoz, hogy néhány speciális algoritmus esetén (ami mondjuk nagyon sokszor dolgozik ugyanazzal a változóértékkel) már a feldolgozott adatok beállított bitjeinek a száma is kimérhető a frekvenciaváltozásból.

Nyilván erre megoldás az, hogy
1) teljesen letiltani a turbo boost-ot (ez szerver oldalon nem is annyira öntökönlövés - egy cloud szolgáltatóval szemben pl eléggé elvárás, hogy a VM-jei konzisztens teljesítményt adjanak, függetlenül attól, hogy a szomszéd ügyfél VM-je mennyire terhelt. Itt a boost kifejezetten kontraproduktív.)
2) esetleg valami limitált boost-ra visszaállni, ami garantáltan mindig a TDP-n belül marad. Ez átlagteljesítményben megintcsak nem akkora érvágás, mert elsősorban ezeket a nagyon rövid és nagyon durva spike-okat kell lenyesni.

Régóta vágyok én, az androidok mezonkincsére már!

Dehogy tiltom le. Nem azért vettem procit, hogy a gyári teljesítményét megnyirbáljam. Nekem egyébként sem tűnik gyakorlatinak ez a támadás, kb. annyira megbízható, mint amikor HDD led villogási frekijéből akartak adatot kiolvasni, ami már akkor nevetséges volt, most meg már SSD-n lehetetlen elvileg is, mert azok olyan gyorsak, hogy a LED-nek vagy nincs ideje kigyulladni, reagálni, vagy állandóan világít tartós terhelésen, de nem villog, illetve sok gépen, főleg laptopokon már LED sincs hozzá. Eleve azonos procik is különböző mértékben boostolgatnak, függően, hogy milyen hűtés van rajtuk, hány fokos a környezet, az alaplapi VRM-ek mennyi delejt tudnak a procinak nyomni, illetve a szilikonminőség is ingadozhat azonos termékvonalon is. Igazából ez még a kriptoalgoritmus implementációja és OS függvényében is változhat, függhet az UEFI BIOS-tól is, a gyártó által szabott TDP-től, Linuxon meg az egyes disztrók is máshogy boostoltatnak, mivel más-más CPU governort használhat a kernel. Annyira sok a változó az egyenletben, hogy egy adott random gép procijának boost idejéből semmit se nem tudnak megfejteni, azt főleg nem, hogy mit csinált a crypto. Adott esetben futhat a háttérben valami sallang is, az is módosíthat a boosidőkön.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Szerintem felreerted, hogy mirol van itt szo. Azt elfogadom, hogy a "logoja van" c. agyrem miatt a szakmabeliek sem tudjak a helyen kezelni, mert azt hiszik, hogy ez ugyanolyan sulyossagu, mint a heartbleed vagy a meltdown volt - ezek ugyanis tenyleg eleg parak voltak, amiket azonnal exploitalni lehetett. Ragaszkodjuk szigoruan a paper-hoz (https://www.hertzbleed.com/hertzbleed.pdf).

Ez egy ujtipusu tamadasi modszert irt le. Ezzel fogjak feltorni holnap a random debian szervereket? Nyilvan nem. Viszont egy fontos figyelmeztetes, hogy a turbo boost feature-ok ilyen iranyu fejlesztesei nemhogy "kockazatosak", de mar el is ertek azt a szintet, amikor demonstralhato tamadast lehet alapozni rajuk. Illetve, hogy a konstans futasi idot igenylo crypto algoritmusoknal ujabb kockazati tenyezovel kell szamolni.

Rohanni kell mindenkinek most azonnal letiltani a turbo boost-ot? Nem hinnem:
- ugyesen kellett hozza crypto algoritmust valasztani (ez a SIKE valami post-quantum kulccsere protokol, aminek manapsag meg nincs sok relevanciaja), mas algoritmusokkal messze nem volt ennyire szignifikans az eredmeny
- az egyik crypto algoritmus ellen 36 ora a masik ellen 89 oraig tartott a teljes kulcs kinyerese - nagyreszt a hibajavitashoz szukseges elkepesztoen sok mintavetel miatt. Ezalatt vegig megvalasztott ciphertext-tel kell a tamadonak soroznia a szervert.

Jelen pillanatban ennek tobb az elmeleti jelentossege, mint a gyakorlati. Az, hogy ez szakmai oldalon hir van belole, azt helyesnek tartom - ettol szakmai oldal a szakmai oldal. Azt, hogy altalanos mediahiszti van korulotte az kontraproduktiv.

Régóta vágyok én, az androidok mezonkincsére már!

A hozzászólás (mint a hasonló többi amit tőled olvastam) csak azt mutatja, hogy képtelen vagy elfogadni, hogy az informatika a dinamikus fejlődési állapotban lévő iparág. Szerintem jó tenne neked ha ezen túl tudnál lépni és a valós problémákkal foglalkozni az árnyékbokszolás helyett.

Attól még egy csomó dologban tényleg igaza van. Az általad említett "dinamikus fejlődési állapotból" a játék egy csomó résztvevőjének tényleg csak a dinamizmus van meg, a fejlődés valahogy nincs. Avagy attól, hogy marha gyorsan haladunk, az irány még lehet teljesen téves.

Itt most nem ez a helyzet, de a szoftverek "fejlődése" például számos esetben tényleg nehezen tekinthető pozitívumnak, amint arra Hajbi Kolléga volt szíves megszámlálhatatlan esetben rámutatni.

Science for fun...

Nekem van példám.

De vicces volt az is, amikor arról írt, hogy mellőzni kéne a Spectre/Meltdown javításokat, leszedték róla a keresztvizet, majd két héttel később az ms maga is inkább letiltotta őket.

Oldschool Computer - http://oscomp.hu

"Kriptográfiai implementációk felkészülnek az értelmetlen belassításukra"

Mi abban az értelmetlen™, ha a jelenlegi formájukban; mint kiderült nem alkalmasak arra, amire kitalálták őket. Ha lassabban kell futnia ahhoz, hogy jó eredményt adjon, akkor eddig volt az értelmetlen™ a gyorsításuk. A számológépben sem az a jobb, ami a 2+2-re azonnal rávágja, hogy 5, inkább várjon egy kicsit, és írja ki utána, hogy 4.

Nagy Péter

Mert, amikor megvásároltam, akkor nem erről volt szó. A gyártó részéről pedig zéró a felelősségvállalás. De mit is várunk egy nagyvállalattól?! Az számomra elfogadhatatlan, hogy a stúdióban a tökéletesen működő rendszer (a 2+2 mindig 4) egy frissítés után belassul ezek miatt a szoftveres maszatolások miatt. Ez nem fejlődés! Ez burjánzás!

Na igen, a gazdaságos működés alapfeltétel. Meg a folyamatos növekedés. Ha nem lenne ez az eszement kényszeres tempó, akkor valószínűleg nem jutunk el idáig. Vagy a szándékosság van benne vagy eleve tudtak a spekulatív problémáról, csak szőnyeg alá söpörték, mert ugye a gazdasági érdek mindent felülír. Mindenesetre a Spectre/Meltdown óta nem igazán látok olyan törekvéseket, hogy hardveres megoldások születnének erre a problémára.