GoFetch - sebezhetőség az Apple M szilíciumokban, javítása nem lesz egyszerű

Apple

Go's RSA-2048 Key Extraction on Apple m1

A newly discovered vulnerability baked into Apple’s M-series of chips allows attackers to extract secret keys from Macs when they perform widely used cryptographic operations, academic researchers have revealed in a paper published Thursday.

Úgy fest, hogy az Apple M-sorozatú SoC-jeit is jobban szemügyre vette a security közösség. A hibának saját weboldala és logója van, tehát komoly. :) Mivel a probléma egy mikroarchitekturális side-channel attack (processzor dizájnt érinti), javítani nem lesz egyszerű (ha lehet egyáltalán), a mitigálása pedig csak teljesítményvesztés árán lehetséges:

We have mounted end-to-end GoFetch attacks on Apple hardware equipped with m1 processors. We also tested DMP activation patterns on other Apple processors and found that m2 and m3 CPUs also exhibit similar exploitable DMP behavior.

[...]

Finally, we found that Intel's 13th Gen Raptor Lake microarchitecture also features a DMP. However, its activation criteria are more restrictive, making it robust to our attacks.

[...]

PoC? Yes, we will release it soon.

[...]

We disclosed our findings to Apple on December 5, 2023 (107 days before public release).

További részletek:  https://twitter.com/search?q=GoFetch&src=typed_query

( trey | 2024. 03. 22., p – 08:35 )

Szerkesztve: 2024. 03. 22., p – 08:39

Milyen jól jönne most egy microcode update lehetőség, nem? M4-re talán befejezik azt is a floor plan-en.

trey @ gépház

Lehet nem vettek komolyan, mert el akartak tusolni a letezeset is. Ezert mondom: publikalas utan varjunk par hetet.

A felelmem: lesz "patch" (workaround), de annak hatasara az M1 harmadolyan sebessegu lesz, mint az M4. :( Es meg kedvem se lesz megvitatni hajbazerrel, hogy akkor ez most extraprofit remenyeben babzsakfejlesztok altal belepatch-elt tervezett elavulas-e epp. :(

A teged is erinto masik felelmem: kiderul, hogy szinte minden ARM CPU-t erint (mint anno a Spectre miutan eloszor csak Meltdown volt).

Kurvara remelem, hogy nem lesz igazam!

Lehet nem vettek komolyan, mert el akartak tusolni a letezeset is.

ROTFL

Ezert mondom: publikalas utan varjunk par hetet.

Gondolom majd azzal együtt jelentik be, amikor közlik, hogy miért tettek backdoor-t a HW-ba.

A felelmem: lesz "patch" (workaround), de annak hatasara az M1 harmadolyan sebessegu lesz, mint az M4. :(

🤷‍♂️

A teged is erinto masik felelmem: kiderul, hogy szinte minden ARM CPU-t erint

Rettegek is miatta!

trey @ gépház

( bzt | 2024. 03. 22., p – 09:41 )

Szerkesztve: 2024. 03. 22., p – 09:46

Én ezt egyáltalán nem látom problémának. Biztonságos megoldásnál eleve sosem használnék CPU specifikus utasításokat, csak általános CPU utasításokkal implementált megoldást. Azt nem is lehet ilyen módon ellopni. A mai számítási kapacitás mellett pedig nem lényeges a teljesítményveszteség. (Lásd pl itt, az assembly-ben írt sha elég rohadt gyors, 133MiB/s, intel sha extension utasításokkal sem jelentősen gyorsabb, de még a portolható C-s verzió is simán hozza a 118MiB/s-t.)

RSA esetében meg különösen nem lényeges a sebesség, mivel azt sosem használják stream encryption-re, csakis egyetlen egyszer a csatorna megnyitásánál a kulcscserére. Ott meg aztán bőven belefér, még ha kétszer annyi ideig is tart.

Azt sokkal aggályosabbnak látom inkább, hogy eleve beletervezték a titkosító kulcsok ellopásának lehetőségét a csipbe. Mert azt nem kajálom be, hogy "véletlenül" került be ez a sebezhetőség, ahhoz túl célszerű és specifikus egy hiba, ráadásul a hasonló side channel attackok sem voltak épp ismeretlenek, amikor ezeket az M csipeket tervezték.

Szerintem félreérted a jelenlegi problémát. Amiről beszélnek az egy automatikus prefetch funkció a processzorban, ami (szokás szerint) megpróbál előre dolgozni, megtippeli honnan kellhet majd olvasni a memóriából, és azt az adatot megpróbálja behúzni a cache-be jó előre. Ezen semmit nem segít, ha nem használsz "CPU specifikus" (gondolom modell-specifikusra gondolsz) utasításokat. Sőt éppen ellenkezőleg, úgy lehet védekezni ellene, ha egy modellspecifikus regiszterbe beírsz egy bitet, ami átmenetileg letiltja ezt a prefetch funkciót.

Mi a baj?

1. Az, hogy ez a DIT bit, ami letiltaná prefetch-et, csak az M3-as generációban van benne. Az M1 és M2-ben nincs, és nem tudni, hogy utólag valami mikrokód frissítéssel ki lehet-e vezetni.

2. Hogy mostantól az összes programnyelven elérhető összes crypto library-be bele kell gányolni egy assembly betétet (szerencsés esetben a fordítónak valami hint-et), ami ki-be kapcsolgatja a DIT bitet a kritikus szakaszok előtt és után. Vagy globálisan letiltani, de az meg mindennek agyonveri a teljesítményét,

Nem hinném, hogy ebből bármi szándékosan lett volna így beletervezve. Ha valódi backdoort akartak volna, akkor nem úgy csinálják, hogy valami kutató csak úgy szisztematikusan rátaláljon. Pláne, ha kiderül (mint most), akkor javítaniuk kell, mert az M1, M2 generáció még bőven a support időszakon belül van. És láthatólag csak az M3-nál kapcsoltak, hogy ezt kikapcsolhatóvá kéne tenni.

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

Rosszul látod, pont fordítva van.

megtippeli honnan kellhet majd olvasni a memóriából, és azt az adatot megpróbálja behúzni a cache-be jó előre.

Hát ez az, a specifikus crypto extension utasításoknál nagyon is jól behatárolható, hogy mit fog olvasni a memóriából és hogy milyen formátumban kell azoknak lennie, valamint hogy a context-et hogy tárolja a CPU.

Ezen semmit nem segít, ha nem használsz "CPU specifikus" (gondolom modell-specifikusra gondolsz) utasításokat.

Nem, még véletlenül sem modell-specifikus regiszterekről van szó, hanem GPR-ekről és általános aritmetikai utasításokról. Pont az a lényeg, hogy ugyanazokat a műveleteket használja, mint a kód összes többi (nem-crypto) része.

átmenetileg letiltja ezt a prefetch funkciót.

Nem mész semmire a prefetch lehallgatásával, ha nem tudod beazonosítani, a kódban mikor és mit is kellene figyelni, ráadásul még azt sem tudod, milyen formátumú, amit behúz a cachebe. (Csak egy példa, a PolarSSL, OpenSSL és az mbedtls tök más formátumban tárolja és kezeli ugyanazt az RSA kulcsot a memóriában. Már a bigint implementációjuk sem azonos.) A preemptív multitaszking meg ugyancsak megnehezíti a hallgatózást, ha a crypto pont ugyanazokat a regisztereket használja, mint minden más.

Ha valódi backdoort akartak volna, akkor nem úgy csinálják, hogy valami kutató csak úgy szisztematikusan rátaláljon.

Nem létezik olyan backdoor, amit egy kutató szisztematikus kereséssel ne találna meg.

Értem, hogy mit akarsz mondani, csak nem látom, hogy a sebezhetőség weboldalán eddig publikált infók alapján most mi a relevanciája. Beleolvastam a cikkbe is: https://gofetch.fail/files/gofetch.pdf itt nagyon alaposan belemegy a részletekbe, olyan szinten, hogy ez alapján akár reprodukálni is lehet. Végig egy olyan DMP mechanizmusról beszélnek, ami egyformán hat minden kód futtatásra.

Szó sincs benne arról, hogy itt bármilyen crypto utasításkészlet-kiegészítés játszana. A proof of concept-nek egy olyan Go-ban írt crypto implementációt használtak, ami semmilyen specifikus utasításkészletet nem használ. Ráadásul ezekre a poszt-kvantum Kyber és hasonló algoritmusokra jelenleg nincs is semmiféle hardveres gyorsítás beépítve, ezeket teljesen lábbal-hajtós módon közönséges aritmetikai műveletekből kell kirakni.

"ha nem tudod beazonosítani, a kódban mikor és mit is kellene figyelni ... tök más formátumban tárolja és kezeli ugyanazt az RSA kulcsot a memóriában" - javaslom akkor olvasd el a publikációt, szerintem benne lesz a válasz minden kérdésedre és kételyedre. Abban igazad van, hogy a támadást külön-külön ki kell dolgozni minden crypto library-re, és azon belül minden algoritmusra, de egyrészt ez senki nem vitatta. Másrészt a cikk alapján ennek nem látszik semmi elvi akadálya. 4-féle algoritmusra mutatnak be proof-of-concept-et.

"Nem létezik olyan backdoor, amit egy kutató szisztematikus kereséssel ne találna meg." - Ez pont olyan, mint a "ki volt a Top 10 kém" a világtörténelemben c. clickbait összesítések. Minden alkalommal elsütik, hogy a listában hátulról előre haladva a Top 1-es kémhez érve csak annyit mondanak: na ő az akiről nem tudjuk kicsoda, mert ő az aki sosem bukott le.

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

Végig egy olyan DMP mechanizmusról beszélnek, ami egyformán hat minden kód futtatásra.

Pont ez a lényeg. Ha egyformán hat mindenre, és a kérdéses kód futása számtalanszor megszakad (threading és taszkkapcsolás miatt) és ugyanolyan vagy nagyon hasonló kód fut időnként helyette vagy akár pont ugyanaz a kód csak más adattal, akkor a cache-be sem koherens adatfolyamként kerül be a kulcs. Márpedig ha ismeretlen méretű darabokban van a cache-ben, roppant nehéz kimazsolázni a kulcsot, még akkor is, ha pontosan tudod, mit kell keresni.

Ez nyilván nem a megoldás, hanem egy erőteljes mitigation technique. A tökéletes megoldás bármilyen side channel attackre a prefetch kiiktatása, ez nem vitás. Azt mondom csak, hogy szerintem a fenti mitigation teljesítményvesztesége a mai gyors gépeken felhasználói szemszögből simán elhanyagolható, egyáltalán nem olyan vészes, mint amilyennek beállítják. A prefetch teljes kiiktatása egész biztosan még sokkal nagyobb teljesítményveszteséggel járna, több, mint valószínű akkorával, amit már a felhasználó is egyből megérezne.

Egy ideális világban szerintem minden ilyen prefetch-t ki kéne írtani az összes processzorból, és helyette a programozókat kéne korbáccsal hajtani, hogy optimálisabb alkalmazásokat írjanak, és akkor egyáltalán nem is létezne ez a gond. De persze tökéletlen világban élünk, így még jódarabig szopni fogunk a prefetch hátrányaival, és ez architektúra függetlenül újra és újra fel fog bukkanni.

Ez pont olyan, mint a "ki volt a Top 10 kém" a világtörténelemben

Nem egészen. Minden backdoor-nál elvárás, hogy kívülről rá lehessen csatlakozni, és ez nyakoncsiphető szisztematikus kereséssel. Ha ez a hozzáférés nem lenne elérhető, akkor a szisztematikus keresés sem találná meg, na de akkor egy támadó sem tudná használni a backdoor-t. Nyilván el lehet bonyolítani az elérését a végtelenségig, de a szisztematikus keresésnek pont az a lényege, hogy számba vesz minden előforduló lehetőséget, ettől szisztematikus.

Megint megkérdezem, olvastad a cikket, amit linkeltem? Tisztában vagy az ott hivatkozott technikákkal, mint pl prime and probe hogy működik?

Ha igen, akkor tudnod kell, hogy ezek a side channel szivárogtatások _mindig_ statisztikai, valószínűségi alapon működnek. Az exploit sokszor megismétli ugyanannak a bitnek a megszerzését és kiszivárogtatását, amíg a fogadó oldal nem tudja statisztikailag már nagyon nagy bizonyossággal eldönteni, hogy a bit 1-es volt vagy 0. A cache, az ütemezés, a preemptálás zavaró hatása, minden csak annyit változtat, hogy hány próbálkozásból van meg elég nagy konfidenciával az eredmény. Nem véletlen, hogy az ilyen side-channel támadásoknál nem GB/s-okkal zajlik az adat kiszivárogtatása, hanem inkább kB/s-os nagyságrendben. És az sem véletlen, hogy minden ilyen tudományos cikknek kötelező eposzi kelléke, hogy formálisan meghatározzák a "csatornakapacitást", mert ez kb az exploit használhatóságának a fokmérője.

És ha olvastad a cikket, akkor az is világos kéne legyen, hogy a példában használt crypto library-nek 4 különböző megtámadott algoritmusa NEM használt semmilyen CPU-gyorsítást, ezek teljesen mezitlábas aritmetikai műveletekből álltak, amit a Go fordító úgy optimalizált, ahogy tudott. Innentől az elképzelésed arról, hogy ennek bármilyen mitigációs előnye lenne, megdőlt.

"Egy ideális világban szerintem minden ilyen prefetch-t ki kéne írtani az összes processzorból," - van olyan processzor, amiben nincsenek ilyen előredolgozások. ARM little core szériája az in-order architektúra miatt elég védett a spekulatív végrehajtásra épülő támadások ellen. Mivel kifejezetten fogyasztásra optimalizált, ezért az ilyen memória prefetch dolgok is nagyon minimálisan vannak benne. Kérdés, mit szólnának az emberek egy A55-magos macbookhoz...

"Minden backdoor-nál elvárás, hogy kívülről rá lehessen csatlakozni, és ez nyakoncsiphető szisztematikus kereséssel." - Ha konkrétan nyakoncsípted a támadást és megvan a kód, amivel a backdoort kihasználták akkor igen. Az "alvó" aktívan nem kihasznált (vagy csak nagyon célzott titkosszolgálati támadásoknál egyszer-egyszer ritkán elővett) backdoort nem fogod megtalálni. Már 10+ éves irodalma van, hogy milyen módszerekkel lehet ilyeneket keresni (tápfeszültség, időzítések figyelése, RF szórás a chipből, hibainjektálás stb.). Hidd el, ha valaki nem amatőr módon áll neki, hanem képben van a téma tudományos hátterével, akkor tud olyan design-nal előállni, ami kivédi az ismert felderítési technikákat. Onnantól meg kriptográfiai komplexitás kérdése, hogy brute force próbálgatással akár évszázadokig se lehessen beletalálni. Ennek az egésznek komoly katonai alkalmazásai vannak (ellenség által megszerzett fegyver irányítórendszerét ne lehessen reverse engineerelni, viszont legyen "killswitch"-ed ha a saját gyártású fegyvereidet ellened akarják bevetni stb.)

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

minden csak annyit változtat, hogy hány próbálkozásból van meg elég nagy konfidenciával az eredmény.

Nem érted, hogy pont ez a lényege az egésznek?

Minden számítógépes rendszer és algoritmus feltörhető, nincs kivétel. Ezért soha nem is volt cél a törhetetlen megoldás. A lényeg helyette az, hogyha kellően felcsűrjük a szükséges próbálkozások számát, akkor elévül és haszontalanná válik addigra a kulcs, mire megszerzik.

Itt is ez van. Ha sűrűbb időközönként váltod a kulcsot, mint amennyi időbe egy kulcs side channel attack-el megszerezhető, akkor a támadás hatástalan és elvileg sem lehetséges.

A te állításod ez volt: "Biztonságos megoldásnál eleve sosem használnék CPU specifikus utasításokat, csak általános CPU utasításokkal implementált megoldást.".

A cikkben szerepelnek az időadatok, hogy négy - CPU hardveres crypto gyorsítás nélküli - implementációból a kulcs mennyi idő alatt nyerhető ki (11. oldal). Azaz pontosan olyan implementációt támadtak meg sikeresen, aminek szerinted védettebbnek kéne lennie. Itt bőven vannak egyes lépésekre 5-6 perces időeredmények (az RSA-nál a teljes feldolgozási idő minden lépést összeadva 49 perc), ez sajnos azt jelenti, hogy egy TLS session élettartamán belül sikerülhet a kulcsot megszerezni.

Szerintem ezen nincs értelme tovább rágni a gittet.

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

Nálam, egy már nem annyira top hardvernek számító laptopon (semmi extra, múlt genes Ryzen 6800H 16 GB dual channel DDR5 RAM-mal, tmpfs ramdrive-on, /dev/random-ból szedett adathalmazra ráeresztve, minden CPU mitigation engedélyezve van a jelenleg futó 6.8.1-es kernelben) az OpenSSL v3.2.1 az SHA224-ből 1,57 GiB/sec-et tol ki, az SHA256-ból 1,54-et. Ahhoz képest nem valami jó a 118-133 MiB/s, főleg nem pure assembly kódnál, bár lehet ez amiatt van, mert csak 1 szálat használ.

Egyébként ezek a CPU sérülékenységek nevetségesek, még a Meltdown-t, Spectre-t se használta ki egyik ártó kód se. Ez csak ilyen biztonsági hype lett, ami fel van fújva, meg csak arra jó, hogy állandó fontoskodás legyen körülötte, meg a régi procikat valamire hivatkozva el lehessen avultatni, meg biztonsági foltokkal mesterségesen lelassítani, hogy újat vetessenek, ebben hajbazernek igaza van.

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

( dotnetlinux | 2024. 03. 22., p – 22:26 )

Szerintetek az MI mennyi idő alatt és mennyi ilyen sebezhetőséget találna meg? Nullát csak az első kérdésre adott válaszban fogadok el.