Názory k článku
Nejnovější procesory AMD a Intel jsou stále náchylné ke spekulativním útokům

Tak teď nějak nevím: jde o "nejnovější procesory AMD", jak se píše v nadpisu, nebo o ZEN v první a druhé verzi, jak se píše v textu?

Who is affected?

Intel Core 12th–14th generation, Xeon 5th-6th generation. Linux users on AMD Zen + and Zen 2. We also observed a faint signal on Zen 3, but it is unclear to us if it is exploitable.

Ani Zen 3 ovšem není nejnovější procesor AMD. ;-)

Tento měsíc vyšli nové CPU založené na ZEN 3. Například Ryzen 5 5600XT je něco mezi low-end a mainstream. A chystají se ZEN 3+ handheldy.

Ale to je jedno, protože zranitelnosti není v Ryzenech. Je v kernelu a nebo v intelech.

Jedna se o spekulativni provadeni anebo spekulativni nadpis?
Kdo ma jeste Zen 1?

Jeden můj kolega má ZEN 1 doma. (Ryzen 5 1500X
Říkal jsem mu, že za pár tisíc může mít 2x lepší výkon. Nechtěl. Stačí mu co má. Ale to je výjimka potvrzující pravidlo. Upgrade udělali snad všichni.

Problém mají majitelé socketu SP3. EPYC a Threadripper bude postižen nejspíš také.

29. 10. 2024, 23:17 editováno autorem komentáře

mam Ryzen 5 Pro 2400GE v "Lenovo Tiny M715q Gen2", neni to me primarni "PC", ale v Passmark to ma koukam vyssi vysledek nez muj primarni NB s iCore 8gen ;-)

nicmene otazka asi nemela byt kdo ma Zen1, ale proc je Zen1/2 nadpisem v kategorii nejnovejsich procesoru od AMD ;-)

Podobný počítač má určitě spousta lidí.
Já sám mám doma jedno PC, kde je Ryzen 5 1600, a před měsícem jsem upgradoval domácí server, kde doteď byl Athlon II X4 605e.

A nebude lehci proste najit reseni/mechanismus, kdy na svem pocitaci budu poustet pouze svuj kod?

Podobnou cestou se totiz ubralo Mac OS - kde mate podepsany moduly i aplikace.. a pokud chcete pustit neco jineho, tak bud vam to dovoleno neni, nebo s vystrahou / vypnutim ochran.

A ze to nejde delat u cloud provideru? Ti jsou mi ukradeni, to je biz, ktery by stejne nemel existovat (je to jednoduse vzdy to horsi a drazsi reseni).

A co web se všemi javascripty, atd.?

A ono v javascriptu lze napsat strojovy kod, ktery by pristupoval na jakekoliv adresy? Mel jsem za to, ze je to memory managed a nativni pole tam ani nejsou a vsude se kontroluji bounds.

A pak - aplikace taky nedokazou asi jen tak vynutit cteni z nejake fyzicke adresy - a veskera ta saskarna se odehrava v ramci procesu. Takze bud potrebujete kernel exploit, nebo zvysene prava (roota), pokud by aplikace mela ziskat nejakou tajnost.. a pokud to je cele ve VM, tak zas nema jak prekrocit dalsi uroven mapovani protoze ty fyzicke adresy nejsou skutecne fyzicke.

LT to rekl spravne - jsou to teoreticke chyby.

Jo, javascript je plnotučný kód který běží ve virtuální mašině. Takže může dírama a vedlejšími kanály útočit na všechno ostatní na daném stroji. Že je to memory safe kód je úplně jedno, protože ten útok obchází ochranu paměti, přes kterou by se ani unsafe Cčko nemělo dostat.

Průšvih těchhle spekulativních útoků je pak v tom, že takovému javascriptu pak stačí nevinně vypadající věc jako přesný timer, aby se mohl dostat k paměti, ke které by správně neměl mít přístup.

Kdyby to byla jen teoretická chyba, tak by prohlížeče nemusely záměrně zhoršovat přesnost časovačů. Nebo spíš "teoretická chyba" znamená jen to, že byli jednou ti hodní rychlejší a stihli to zalepit než se stal průser.

"utocit" je ponekud silne slovo, ale budiz.

Zranitelnost se spekulativni vykonavani kodu umozni zjistit, zda na adrese X se nachazi hodnota Y. Kdyz to udelate v cyklu, pro Y=0..255, tak muzete rict, ze dokazete precist pamet na adrese X.

A ted pozor: adresa X je z mnoziny VA, virtualnich adres procesu, ve kterem bezi "utocici" kod. Takze dokazete precist pouze to, co by jste precetl v unsafe skrze (char*)(adresa) - zadne tajemstvi tam nebyva* - pokud se nejedna treba o single-process browser, coz je to, co se patchovalo a stranky bezi ve vlastnich procesech na modernim browseru. Proste vlakno muze cist pamet jinych vlaken.. a k tomu nepotrebuji zranitelnost (konecne si to uvedomili i v sshd a bude rozdelen na ruzne casti s oddelenymi procesy).

A ted k te * - z duvodu vykonove optimalizace, je pamet pouzivana v kernelu porad mapovana do VA (proto napr. historicky na 32bit OS bylo rozdeleni 2GB/2GB nebo 3GB/1GB). V teto oblasti se uz muze nachazet neco zajimaveho - rekneme pri worst case neco jako klic k sifrovani disku. Pokud jste v user-mode, tak (char*)(adresa) na tyhle regiony nefunguje, protoze procesor pracuje spravne s izolaci co se tyce urovni opravneni, u spekulativniho vykonavani tohle nebylo kontrolovano a tak muze proces cist pamet jadra na kterem bezi.

A tu pamet jadra si to jadro vystavilo/zpris­tupnilo samo - a resi to patch pro KPTI/PTI - page table isolation, kdyz uz tedy procesor je deravy.

Ale zpet k problemu - ceho si myslite ze dosahnete, pokud budete mit neomezenou moznost pamet cist? Jak jsem zminoval, rezidentni bude klic k sifrovani disku.

Co by jste z pameti procesu/jadra precetl a jak toho vyuzil k nejake eskalaci prav ci RCE??

Mno říkat kódu schválenému nadnárodním megakorporátem "svůj kód" je kapku úsměvné.
Hlavně proto, že vy do toho procesu nemáte co kecat. ;)

Tak to vypada ze uz si svobodny nebo svuj kod nepustite.. jenom podepsany:

https://www.youtube.com/watch?v=sT_ePyytBtc

"Intel users should make sure their intel-microcode is up to date," the researchers said. "AMD users should make sure to install kernel updates."

Takže intel si musí opravit CPU.
AMD má CPU v pořádku. Ale pro změnu to rozbil OS.

Podle mě tam bylo nějaké domluvené časová prodleva, od kdy se budou zveřejňovat další informace, prezentovat výzkum, exploity atp. Což je teď až po to, kdy na to oba výrobci zareagovali.

Intel má ty aktualizované mikrokódy už víc jak půl roku. Když jsem se koukal do changelogu v SUSE balíčku, tak je to přidáno do verze s datem 13.3.2024.
RHEL víceméně také.
Pro kontrolu by si mělo stačit v distribuci progrepovat changelogy, buď na CVE-2023-38575 nebo interní intel ID SA-00982.

Pro AMD (ZEN < 4) je teď asi týden patch přijatý do jádra..
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ade8ff3b6aca47c234e5353b1e9dc1e5a8f21ffe
Doufám, že jsem to dohledal správně a je to ono.
Takže se dá předpokládat, že to vyjde v další verzi vanilla jádra a případně to bude backportované do nějakých distribučních verzí s delší podporou.
Ale jak je psáno v popisku commitu, musí se explicitně zapnout ibpb kernel parametrem, aby to mělo nějaký efekt.