Vlákno názorů k článku
AMD Zen 1-4 nekontrolují správně podpis mikrokódu od Jakub Štech - Jaká je praktická zneužitelnost? Když už se někdo...

Jaká je praktická zneužitelnost? Když už se někdo dostane do situace, že může nahrát upravený mikrokód, tak má buď:

- write přístup do /lib/firmware a /sys/devices/sys­tem/cpu
- write přístup do obrazu jádra/initram­fs/nastavení zavaděče
- write přístup do distribučních balíčků s výše uvedeným

což je ve všech případech už stejně absolutní prohra a nějakej podpis mikrokódu to nezachrání, protože před i po jeho aplikaci na stroji může útočník udělat úplně všechno.

Pokud se ten modifikovanej mikrokód zapíše do UEFI, tak pak bude děravej jakejkoliv počítač, který bude onu nahackovanou desku používat (takže třeba výhodné pro distributora :-D ).

V čem je to pro útočníka lepší než útočit přímo na UEFI? Napsat payload pro EFI je triviální, jsou na to i tutoriály, nic kromě LLVM nepotřebuju... zatímco mikrokód je daleko náročnější cíl. V čem je teda ta výhoda?

Z informace v článku:
"AMD opravilo mikrokód zatím u CPU EPYC"
Předpokládám že se bavíme o pronájmu virtuálních strojů.
Kde si navzájem nevěří majitel HW a pronajímatel virtuální stanice.

Vy by jste si pronajal HW, který generuje "náhodná" čísla?
Klaiscky jako většina chyb nebude mít vliv na stroje schované za IPv4 NATem.
V případě IPv6 za Firewallem.

10. 2. 2025, 15:25 editováno autorem komentáře

Pokud jako zákazník využívající VM nemůžu důvěřovat provozovateli a jeho hypervizoru, pak je úplně nepodstatné, na jakém HW nebo SW tu VM vlastně provozuje.

Ne tak úplně. Kvůli tomu existují featury jako SEV a celý hype kolem Confidential Computing. A když se podíváte na ten link o opravě pro Epyc, tak asi není úplně náhoda, že nadpis zní AMD SEV Confidential Computing Vulnerability.