Vlákno názorů ke zprávičce Nejnovější procesory AMD a Intel jsou stále náchylné ke spekulativním útokům od RDa - A nebude lehci proste najit reseni/mechanismus, kdy na...
-
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 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/zpristupnilo 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??
ČLÁNKY DO MAILU