Dle dostupných zpráv, které se začaly rojit na Nový rok, možná čeká společnost Intel jeden z nejhorších průšvihů v historii. Postiženy mají být ale i procesory dalších výrobců.

V posledních letech se nejedná o jediný větší aféru, můžeme připomenout TSX bug v roce 2014 (Haswell/Broadwell), potíže s procesory Atom řady C2000 a možná i jiných (který stále dopadá na uživatele síťových úložišť, miniserverů, síťových prvků apod.). Další je poslední měsíce rozmazávaná platforma IME (Intel Management Engine), což je věc, která se zatím příliš nikam nehla, přitom je to potenciálně otevřená díra do spousty zejména pracovních počítačů, jelikož v nich běží a zpravidla se ani nedá prokazatelně vypnout. Nynější problém ale svým rozsahem může být ještě o řád horší, protože je zneužitelný mnohem snáze a bez jakéhokoli fyzického přístupu k počítači (s IME byly zatím předvedeny pouze útoky s přístupem k zařízení).

Co se na nás řítí?

Pokud to krátce shrneme, před pár měsíci se objevily nové možnosti útoků přes virtuální paměť s cílem převzetí kontroly nad počítačem z uživatelského prostředí, a to dokonce i uživatelskými interpretovanými skripty (např. Javascript), nikoli pouze přímo spustitelnými programy (binárky). S ohledem na to, že skripty jsou dnešní weby naprosto přecpané a jejich potenciál si nyní uvědomují i provozovatelé botnetů např. pro těžbu kryptoměn (typu CryptoNight a podobných), snad každému je zřejmý potenciál tohoto průšvihu (zasloužilo by si to už i jiné označení).

Potenciálně je možné nejen propašovat do paměti binární kód a převzít kontrolu nad HW, ale i (jen) číst obsah vyhrazené paměti jádra systému a tak se dostat např. k HW/SW klíčům, heslům a vlastně takřka jakýmkoli datům v paměti. Poměrně záhy začaly v historii téměř nevídaným tempem vznikat téměř anonymní a nedokumentované opravy v samotném core linuxového kernelu, které nyní začínají být nasazované. Současně i Microsoft začal urychleně pracovat na aktualizacích pro jádro jejich operačních systémů, které mají přijít příští úterý. Z prvotních testů, které jsou nyní k dispozici, vyplývá, že řešení na úrovni operačního systému může mít za následek zpomalení někde mezi 0 a 75 % s tím, že nejvíce asi problém dopadne na velké providery cloudových a virtuálních služeb, kteří mohou čelit propadu výkonu mezi 5 a 30 %.

Podle vyjádření Toma Lendackyho z AMD se problém netýká procesorů společnosti Advanced Micro Devices. Intel nechtěl zveřejnit podrobnější informace, dokud nebude k dispozici řešení, v reakci na množící se články ale včera přišel s předběžným vyjádřením, ve kterém se ostře ohradil proti tomu, že by byly problémem stiženy pouze procesory Intel, ale má se týkat i mnoha dalších výrobců čipů a řady operačních systémů. Intel ve svém vyjádření nepopírá, že budou mít opravy za následek pokles výkonu, ale míra zpomalení má být závislá na typu zátěže a časem by se měla snížit. Domácí uživatelé počítačů by pak podle Intelu neměli pocítit významný dopad na výkon. 

Virtuální paměť, chráněný a uživatelský režim

Pro ty, kdo se – stejně jako já – v této oblasti nepohybují a tak o tom mají informace jen velice povrchní (nebo to už dávno zapomněli), se pojďme ve stručnosti podívat, o čem se bavíme. Programy v moderních operačních systémech nepracují přímo s fyzickou pamětí, ale pracují s mezivrstvou spravovanou operačním systémem, virtuální pamětí. Ta je u všech významnějších systémů rozdělená do segmentů (stránek). Operační systém přiděluje stránky, vede si stránkovací tabulku (aby věděl, co je kam přiřazeno) a následně teprve umisťuje data z virtuální do fyzické paměti (zpravidla operační paměť RAM, různé vyrovnávací paměti v procesorech, ale i stránky na pevném disku). Program dostane vyhrazenou jistou spojitou část a o přiřazení reálné fyzické paměti se pak stará operační systém, přičemž překlad zajišťuje k tomu určená jednotka uvnitř mikroprocesorů. Systém podle svého uvážení s fyzickým umístěním dat různě šachuje dle potřeby (umístění v RAM či na sekundární úložiště jako stránkování, také nazýváno swap). Je poměrně zásadní vlastností, že různé programy mají každý svou vlastní virtuální oblast a nesmí sahat, ba ani vidět do virtuálního prostoru těch ostatních. Všechny běžné programy běží v tzv. uživatelském režimu.

Operační systém, resp. jeho jádro, běží v úplně odlišném, privilegovaném režimu jádra. Má také svůj vlastní virtuální adresní prostor. Tam běží i mnoho ovladačů, z čehož právě tak často vyplývají problémy s nestabilitou (špatně napsaný ovladač, případně HW problém, může vést k tomu, že jeden proces, např. ovladač, zapíše něco někam, kam nemá, což pak vede k pádu jádra a tím celého systému). Režim jádra dává všemu v něm provozovaném mnohem bližší přístup k HW, moderní procesory mají přitom přímo implementované mechanismy pro oddělené spouštění instrukcí v režimu jádra a v uživatelském režimu. Kdykoli nějaká aplikace potřebuje někam přistoupit (číst, zapsat), dojde k tzv. přerušení, kernel vykoná pár cyklů, provede HW operaci a vrátí prostředky programu. Výrobci mikroprocesorů x86 (tedy Intel, AMD a VIA) samozřejmě jdou uživatelům naproti a implementují mnoho mechanismů, jak nejrůznější procesy zrychlit a namísto SW řešením to řešit na úrovni mikroprocesoru složitějšími instrukcemi (tedy obvykle rychleji, s využitím méně instrukčních cyklů) přesně v souladu se zaměřením architektury (CISC). S rozmachem virtualizace před zhruba dekádou právě došlo současně s uvedením nové architektury procesorů Core, Nehalem, k nasazení výrazně vylepšené podpory virtualizace, a to i právě v oblasti práce s virtuální pamětí. Mnoho těchto mechanismů zůstává aktuálních doteď.

(K)ASLR

V Linuxovém jádře se za poslední zhruba rok událo poměrně mnoho změn, které téměř zcela překopávají systém práce s pamětí. Jednou z nich je koncept ASRL, Address Space Layout Randomization (randomizace rozložení adresního prostoru). Mj. díky práci rakouské Graz University of Technology byly odhaleny způsoby, jak se dostat k informacím o fyzickém rozmístění dat v paměti u dřívějších verzí systémů, kde jádra typicky uchovávala části dat ve stále stejných oblastech. Ty se daly díky chybám v jaderných aplikacích jistými způsoby práce s pamětí odhalit, nepovoleně rozšířit adresní prostor aplikace (aplikací) v uživatelském režimu a z oblastí programů v chráněném režimu pak číst, nebo do nich i zapisovat. Byla tak implementována metoda randomizace, která chráněné aplikace laicky řečeno „rozháže“ při každém spuštění na jiné místo, aby tak byla podstatně ztížena jakákoli možnost škodlivého kód zjistit, kde má jádro svá citlivá data umístěna. Není to přímo řešení, ale fakticky učiní pravděpodobnost úspěchu útoku předchozím způsobem blízkým nule. Jaderný ASLR (kernel ASLR či KASLR) tak má za cíl rozházet data jádra a jejich umístění před programy v uživatelské oblasti bedlivě tajit. V tomto však SW výrazně spoléhá na to, že HW, tedy zejména mikroprocesor, zajistí důkladné oddělení instrukcí v režimu jádra a instrukcí v programovém režimu.

Záhy však byly teoreticky popsány způsoby, jak KASRL úplně obejít právě zacílením útoku na HW, tedy mikroprocesor. Mezi jinými zejména útokem na TLB (transaction lookaside buffer), což je malá interní cache právě v jednotce pro zpracování paměti v procesorech (typicky mezi každou úrovní paměti), kam si jednotka ukládá poslední pozice překladů virtuálních adres na fyzické, aby si ušetřila čas při dalším volání. Někdo si možná vybaví aféru kolem TLB chyby u procesorů AMD Phenom, při které ve specifických případech mohlo dojít k poškození dat přesouvaných mezi cache procesorů (data byla v několika cache současně a mohlo dojít k jejich změnám na jednom místě a následně ke kolizi). ASLR a KASLR přímé metody řetězením škodlivého kódu do fragmentů (např. s využitím return-oriented programming/ROP) v podstatě znemožňují, neboť náhodné využívání paměti již aplikacím znemožňuje se dostat k informacím o tom, co kde v paměti je. Dá se však k nim dostat přes „postranní kanály“, například právě snahou dostat se do TLB. Dále jsou indicie, že problémy s TSX u některých procesorů v roce 2014 mohly vést právě i k úniku takových dat. Konkrétní už dříve využívaný způsob spočíval v tom, že aplikace záměrně vyvolala chybu typu page fault (přístup do paměti, která není adresovaná pro tuto aplikaci) a měřila si čas zpracování této chyby. Pokud tam nějaká data byla, opakování trvalo kratší dobu a kód tak mohl postupně zjistit, že v dané oblasti skutečně „něco je“, a to dál zneužít. Instrukce TSX toto řešila mnohem rychleji uvnitř procesoru, bez operačního systému, kód se tak dozvěděl stejnou věc mnohem rychleji a spolehlivěji. To Intel vyřešil vydáním mikrokódu, který TSX zcela vypnul.

Další metody se zaměřily na využití chyb v predikčních funkcích procesorů, které jsou jedním ze způsobů, jak výrazně mezigeneračně zvyšovat výkon. (Princip je takový, že procesor analýzou kódu odhaduje, jaké instrukce mohou být potřeba příště, a sám je už předem nahrává do paměti.) Tak se dala zjistit nejen platnost programu nedostupné virtuální adresy, ale i její velikost. V Linuxu mohl útočník dokonce SW prefetchingem zjistit i přesnou fyzickou adresu pro něj nepřístupné části virtuálního adresního prostoru.

Podezření na problém

Zcela dle doporučení Intelu při vývoji moderních OS došlo k tomu, že pro zrychlení operací systémy alokují části jádra přímo do oblastí aplikací v uživatelském režimu. Když pak program zavolá jádro přerušením, tak je načtení modulu a vykonání operací jádra rychlejší. Zabránění přístupu k těmto sekcím je zařízeno nižšími právy uživatelské aplikace uloženými v tabulce v procesoru. K tomu se právě dá postupy popsanými výše za jistých okolností dostat, nebo to obejít a přístup umožnit i neprivilegované aplikaci. Jedním z řešení by bylo striktně oddělovat oblasti uživatelské a jaderné paměti, což si ale vyžaduje poměrně značné přepsání konceptu jádra a navíc to má zásadní vliv na výkon, kdy je nutné často zcela vyprazdňovat cache procesorů a data tak načítat stále z operační paměti. To jde přesně proti konceptu dnešních procesorů a systémů, kdy je snaha naopak zbytečně velká kvanta dat nepřesouvat sem a tam. Rakouský tým sice přišel s návrhem konceptu KAISER (Kernel Adress Isolation) kterak za pomoci zcela nového šedého adresního prostoru problém vyřešit za údajně téměř nezaznamenatelného propadu výkonu (viz materiál KAISR), otázkou ale je, jak se k tomu pak při implementaci postavit.

Dle dění v posledních pár dnech je ovšem zřejmé, že problém je asi výrazně závažnější, než si kdokoli myslel, neboť popisované změny byly v pouhých několika posledních měsících, možná týdnech, implementovány přímo do linuxového jádra, kde se nyní objevují. Co je asi ještě horší je fakt, že dokumentace zcela chybí a popisy v kódu jsou zmatené. To vše naznačuje, že problém je dost závažný, a tak je záměrně udržováno embargo. Očekává se, že podrobnosti budou odhaleny příští úterý s tím, jak vyjdou kritické aktualizace operačních systémů Windows. Systém MacOS od verze 10.3.2 již údajně záplatu obsahuje. Mezitím několik největších poskytovatelů cloudových služeb ohlásilo na 10. ledna výpadek služeb s tím, jak budou instalovat aktualizace od Microsoftu. Utajená aktualizace připravená k vydání je už údajně připravena i u managera Xen. Jakýchkoli poskytovatelů virtuálních služeb se totiž problém dotýká také velice citelně – jak již bylo naznačeno, možnost dostat se do chráněné oblasti paměti znamená, že se může škodlivý kód na virtuálním stroji dostat dokonce i k datům na ostatních VM na tom samém fyzickém stroji. U hypervisoru Xen už údajně dokonce docházelo koncem roku k opakovaným kolům útoků. Že je to hrozba reálná a bug existuje, dokládá i důkaz, který připravil během psaní tohoto článku doktorand na univerzitě Vrije v Amsterdamu.

Z vyjádření vývojáře AMD Toma Lendackyho o tom, že procesory AMD nejsou zasaženy, neboť podobné funkce vůbec nevyužívají, se dá dovodit, že problém by se mohl týkat právě prediktoru v procesorech Intel (a dalších). V rovině spekulací se hovoří o tom, že procesory mohou za určitých okolností vykonat instrukce bez toho, aby si ověřily jejich oprávnění, a tím tak zcela obejít dosavadní opatření ze strany OS k tomu, aby se škodlivý kód nedostal do chráněné oblasti. Teoreticky jde problém řešit třemi způsoby: na úrovni mikrokódu, na úrovni operačního systému, nebo přepnutím procesoru na in-order zpracování instrukcí (což nám výkon vrátí někam k architektuře Atom starší než Silvermont, vycházející z Intel P5 – původní procesory Pentium a Pentium MMX). Spekuluje se, že chyba je tak závažná, že na úrovni mikrokódu rozumně opravit nepůjde, ostatně by tak již Intel nejspíš učinil. In-order také nikdo nechce. Proto bude nejspíše řešena na úrovni OS. Ačkoli to, že časem na úrovni mikrokódu vyřešena bude, je stále ve hře, neboť je možné záplatu (nejen kvůli procesorům AMD) i v Linuxu parametrem vypnout, případně také vůbec neaktualizovat (i když aktualizovat BIOS serveru je snad ještě horší a nedělá to skoro nikdo, když i dnes to nezřídka znamená, že bude do serveru zanesen ještě další problém, který tam před tím nebyl).

Nynější situace je taková, že jako nebezpečné jsou u linuxových patchů označeny všechny procesory Intel, jak informuje server Phoronix. Minimálně momentálně s touto poměrně horkou jehlou šitou záplatou tak bude platit, i přes výše zmiňovanou studii o KAISR, poměrně výrazný výkonnostní propad, který dle počátečních testů v některých aplikacích je zmiňovaných 5–30 %, ve specifických případech ale i výrazně více. Můžeme zatím pouze spekulovat, zda to je tím, že se koncept KAISR neukázal být vhodný, nepodařilo se jej tímto způsobem implementovat (nebo to přijde později), anebo je problém v procesorech tak závažný, že ani KAISR nepomáhá. Podrobnosti se dozvíme pravděpodobně až příští týden. Je pravděpodobné, že některé novější procesory budou časem označeny jako bezpečné. Rovněž ty z posledních generací, které mají instrukci PCID (Process-Context Identifiers) by měly být propadem výkonu zasaženy výrazně méně.

Jak již tedy bylo řečeno, v AMD si nemohli přát lepší začátek roku. Stihli již připravit patch, který nové záplaty u procesorů AMD neaktivuje, těch pár enterprise uživatelů procesorů Bulldozer navíc nyní dostane rovněž pěkný dárek, když všechny konkurenční servery postihne rána, která jejich výkon srazí. I přes zprávy o chystané těžké konkurenci se Ryzeny prodávají jako na běžícím páse (v popisovaném nasazení – stejně jako Bulldozery ve srovnání s Core té doby – překonávají i nynější procesory Intel velice výrazně), EPYC nyní dostane obrovský boost. Kdo chce dobře investovat, měl by rychle uvažovat o nákupu akcií AMD. Jen za včerejšek již zaznamenaly nárůst o 9 %, a to se informace teprve pomalu dostávají na světlo, zatímco Intel se zatím nejníže propadl o 7 % (a pak částečně vyrostl zpět).

Zdroj: python sweetness, The Register

Další články v kategorii

• Der8auer přetaktoval Radeon RX 6900 XT na rekordních 3,2 GHz
• GeForce RTX 3080 Ti v prodeji za oficiálních 1099 dolarů?
• Stahujte z Epic Games tři hry zdarma, zítra bude Alien Isolation
• Apple představil 24palcový iMac s procesorem M1
• Samsung Galaxy M12 dorazí s 90Hz displejem a cenou do 5 000 Kč