"Megkongatták a vészharangot a biztonsági szakemberek: a támadók titkos mikrokódot tölthetnek be a processzorokba, és ezzel az eddigi szoftveres szint helyett hardverszinten avatkozhatnak be a gép működésébe, például közvetlenül futtathatnak zsarolóvírusokat a CPU-n. "
https://hvg.hu/tudomany/20250518_hardverszinten-tamado-zsarolovirus-pro…
- 707 megtekintés
Hozzászólások
"még a Windows újratelepítése sem szünteti meg feltétlenül a fenyegetést" hát nálam biztos nem :) Bár rebootkor törlődik a betöltött mikrokód, nem?:)
Akkor ez lesz az amd spectréje?
Nothing new
- A hozzászóláshoz be kell jelentkezni
Ezért lenne jó dolog ha az ARM és a Risc-V feljönne desktop-ban. Ott (még) nincs mikrokód. Meg kicsit felkavarnák az állóvizet.
- A hozzászóláshoz be kell jelentkezni
Tapasztalat alapján mire eljutnak oda, h. használható általános célú processzoraik elterjedtek legyenek, ugyanazokba a hibákba fognak belefutni, amibe az x86 is belefutott az elmúlt 40+ évben. Hiába tudod előre h. gond lehet valamiből, ha muszáj vagy valami miatt támogatni, ugyanúgy elő fognak állni határesetek, és nagyon nagyon nehezen megoldható, vagy értelmesen megoldható bonyolultságok.
- A hozzászóláshoz be kell jelentkezni
Két gond van ezzel az elképzeléssel.
Az egyik, hogyha történetesen elcsesznek valamit egy implementációban (sose volt még ilyen: https://ghostwriteattack.com/#faq), akkor nincs lehetőség kijavítani, csak a hardver cseréjével.
A másik, hogy tágabb értelemben véve az ARM SoC-knek is van alacsonyszintű rendszer firmware-jük, még ha nem is pont az a szerepe, mint az x86-nál a mikrokódnak. Inkább olyan, mint az AMD-nél az AGESA csomag, amiben a szorosabban vett CPU mikrokódján kívül egy csomó beágyazott mikrokontroller (power management, frequency scaling vezérlés stb.) valamint az on-chip memóriavezérlő és PCI-e vezérlő inicializáló (link training stb.) kódjai is benne vannak. Ha megnézed a Raspberry-nél pl a Videocore GPU-n futó firmware-t használják (abuzálják) erre a célra, az röffent be mindent, mielőtt az ARM CPU egyáltalán el tudna indulni. Biztonsági szempontból pont ugyanannyira kritikus és kockázatos, mint a CPU mikrokód.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Na, ha már te ilyen egyszerűen le tudtad írni, akkor már csak meg kellene valósítani a processzor gyártóknak!
- A hozzászóláshoz be kell jelentkezni
Igen, hvg-s idióta, persze, hogy a szoftveresen betöltött mikrokód rebootkor törlődik, azt minden rendszerindításnál be kell tölteni. Meg ez eleve feltételez már egy malware-rel összefertőzött rendszert, ami már bootkor úgy indul, hogy betöltöget a prociba ilyen extra szutykot, ehhez eleve rendszergarázdai jog is kell. Így ez szerintem nem valódi fenyegetés, mert ha egy rendszer már ennyire elesett, hogy automatikus indulással indulnak ezek a szutykok és rendszergazdai jogokkal is garázdálkodnak, onnan az a rendszer már elesett teljesen, nem is kell CPU mikrokóddal szórakozni külön, hiszen a támadóé már az egész rendszer.
Windows alatt meg eleve van egy két extra nehezítő faktor, a Win10 támogatása ugyebár pár hónapon belül eljár, a Win11-nél meg kötelező a Secure Boot, TPM, emiatt a bootfolyamatba nem is lehet olyan kódot beemelni, ami nincs aláírva, csak akkor, ha valaki Rufus vagy hasonló terminálos trükközéssel tette fel a Win11-et nem támogatott hardverre, kikapcsolva belőle a biztonsági védelmeket, beleértve azt, hogy Win11-nél már a rendszer is eleve virtualizálva fut (VBS), és nem kéne tudnia hozzáférni a procihoz hardveresen.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Megnyitottam a cikket, az eredeti forrásra mutató linket keresve...
Nem lepődtem meg... :)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Szerintem ez az eredeti forrás:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-…
E cikkben egyébként a "Colliding Keys" szakaszcím félrevezető, mivel a "key"-nek az adott kontextusban két értelme van: egyrészt az AES-CMAC-hoz használt titkosító kulcs, másrészt pedig a későbbi RSA-hoz használt nyilvános kulcs -- amely valójában az AES-CMAC bemenete. A támadás tehát igazából egy second-preimage attack; az ütközés valójában a bemenetek között van (amelyekhez az AES-CMAC azonos hash-t generál). Az már egy másik kérdés, hogy ezek a bemenetek maguk is RSA nyilvános kulcsok, tehát így "adódik" a "kulcsok közötti ütközés".
Az mindenesetre nem vált teljesen világossá számomra a leírásból, hogy az AMD hogyan tudta magát az AES-CMAC-et kicserélni, frissítéssel, egy kriptográfiailag erős hash függvényre. ... Nos, az "AMD Microcode Patch Routine / IV) Verification & Installation / 2" (és későbbi) lépések szerint úgy látszik, hogy maga az x86 mikrokód végzi a mikrokód frissítését, miután a 0xc0010020 MSR-be írtunk. Így már érthetőnek tűnik; mikrokód frissítéssel leváltható az AES-CMAC, a jövőbeni mikrokód frissítések ellenőrzésére.
Mindenesetre megint jól látszik, hogy a CPU- (és egyéb elektronikaieszköz-) gyártókat törvényben kellene kötelezni a forrásaik nyilvánosságra hozatalára. Egyértelműen közérdek. A reverse engineering-nek mint iparágnak okafogyottnak kellene lennie.
- A hozzászóláshoz be kell jelentkezni
"We noticed that the key from an old Zen 1 CPU was the example key of the NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until at least Zen 4 CPUs"
Aztaqrva! A cikket olvasva a sztori nagyon abba az irányba haladt, hogy itt valaki valami nagyon szofisztikált hardveres (esetleg hibainjektálásos) módszerrel kinyerte a titkosítókulcsot, de erre a fordulatra azért nem számítottam. :)
Az biztos, hogy így a FIPS megfelelőséggel nem volt gondjuk :)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Bruce Schneier 1996-os "Applied Cryptography, Second Edition" művében szerepel a következő (Part III -- Cryptographic Algorithms, Chapter 18 -- One-Way Hash Functions, 18.11 One-Way Hash Functions Using Symmetric Block Algorithms); kiemelés általam:
It is possible to use a symmetric block cipher algorithm as a one-way hash function. The idea is that if the block algorithm is secure, then the one-way hash function will also be secure.
The most obvious method is to encrypt the message with the algorithm in CBC or CFB mode, a fixed key, and IV; the last ciphertext block is the hash value. These methods are described in various standards using DES: [...]. This just isn’t good enough for one-way hash functions, although it will work for a MAC [...].
[...]
Assuming the hash function is correct, the security of the scheme is based on the security of the underlying block function. There are exceptions, though. Differential cryptanalysis is easier against block functions in hash functions than against block functions used for encryption: The key is known, so several tricks can be applied; only one right pair is needed for success; and you can generate as much chosen plaintext as you want. Some work on these lines is [...].
Kieg.: a "NIST Special Publication 800-38B"-ben egyébként már azt írják (2005. májusában), hogy a CBC-MAC még MAC-ként sem jó (és ezért vezették be a CMAC-et):
The basic Cipher Block Chaining MAC algorithm (CBC-MAC) has security deficiencies [...] The core of the CMAC algorithm is a variation of CBC-MAC [...]
Ettől az még érvényben marad Schneier-től, hogy egy így konstruált hash gyenge pl. second preimage attack-kal szemben.
- A hozzászóláshoz be kell jelentkezni
Nyilván részemről poén volt a FIPS megfelelés, hogy annyira compliant-ek akartak lenni, hogy még a kulcsot is az NIST-től vették. Egy normális auditon ez a megoldás úgy ahogy van fennakadt volna. A default example kulcs csak "megkoronázta" ezt az egészet. (Gondolom a kulcsot eredetileg unit tesztként rakta oda a fejlesztő aki ezt a részt implementálta, aztán mindenki elfelejtette, hogy honnan jött, és hogy a végleges szériagyártás megkezdése előtt le kéne cserélni.)
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Nyilván részemről poén volt a FIPS megfelelés
Igen, vettem -- bocsánat, az én kommentem nem volt egyértelmű. Nem ellentmondani akartam, hanem az egyetértésemet kifejezni.
Schneier könyvét azzal a céllal hoztam fel, hogy még abból is látható (-nak kellett volna lennie), hogy a MAC (akár az AES-CMAC, akár más) általános kripto hash-nek nem jó.
- A hozzászóláshoz be kell jelentkezni
Ez jó könyv arra, ha az ember csak alapszinten akarja megtanulni a crypto vilàg nyelvét, mindenféle algoritmusokba és 20 szintű rabbit-hole-okba belemerülés és madness nélkül?
- A hozzászóláshoz be kell jelentkezni
Nincs elég rálátásom a terület irodalmára, hogy hitelt érdemlően minősíteni tudjam a könyvet; annyit tudok mondani, hogy amikor 20 éve elkezdtem érdeklődni a terület iránt (pont úgy, ahogy te leírod), akkor ezt forgattam, és úgy éreztem, számomra bevált. Van "20. évfordulós" kiadása is, úgy látom, tehát annyira elavult nem lehet.
- A hozzászóláshoz be kell jelentkezni
Gondolom akkor nem adjak meg a forrast mikor chatgpt-vel csak siman forditjak a cikket es ciki lenne megjelolni
- A hozzászóláshoz be kell jelentkezni