Bezpečnostní chyba CrossTalk v procesorech Intel zpomalí programy závislé na RdRand

26

Byla publikována další side-channel zranitelnost v procesorech Intel. Provádění instrukcí jako RdRand mimo jádro umožňuje kompromitování šifrovacích klíčů.

Vypadá to, že tento měsíc opět nebudeme ušetřeni populární rubriky „díry v procesorech“. Minulý týden 9. června byla v rámci většího balíku bezpečnostních oprav zejména pro různý software a firmware publikována také zranitelnost s přezdívkou CrossTalk, která je přímo v architektuře současných procesorů Intel. Oprava bude stát nějaký výkon, ale naštěstí jen ve specifických situacích, které by na desktopu neměly být moc podstatné.

Intel chybě CrossTalk říká „Special Register Buffer Data Sampling“ a přiřadil jí kód Intel-SA-00320; její CVE kód je CVE-2020-0543. Závažnost má podle Intelu střední se skóre 6.5.

Některé instrukce zpracovává CPU mimo jádra

Tato chyba spočívá v tom, že určité operace v CPU jádrech současných procesorů Intel nejsou zpracovávány lokálně, ale mimo jádro v „uncore“ čipu, kde je daná jednotka sdílená mezi všemi jádry. Výzkumníci z nizozemské Vrije Universiteit a z ETH Zürich objevili, že procesory mají společnou frontu, tzv. staging buffer, v které jsou společně požadavky na tyto sdílené zdroje. Problém je, že kód běžící na jednom jádře má k této frontě plný přístup a může přes ní šmírovat kód běžící na dalších jádrech, nejsou od sebe izolovány.

Takto sdílené nemohou být samozřejmě žádné standardní výpočetní jednotky kritické pro výkon. Ale výzkumnici zjistili, že mimo jádra a sdílený je generátor náhodných čísel volaný instrukcemi RdRand a RdSeed. Požadavky na tyto operace jdou právě do onoho staging bufferu a výzkumníci na nich demonstrovali bezpečnostní rizika tohoto uspořádání.

Staging buffer obsahuje přímo výstupy generátoru, takže program může číst náhodná čísla pro programy běžící na jiných jádrech. Což je riziko na serveru, protože na nich při virtualizaci běží zcela jiný klient. Problém je, že náhodná čísla se používají při kryptografii a jejich znalost může vést k úniku či prolomení šifrovacího klíče, který se pak dál dá využít ke krádeži vašich dat.

Chyba CrossTalk: Staging Buffer a přes něj přístupný generátor náhodných čísel v procesorech Intel jsou sdílené pro všechna jádra Zdroj: VUSec: CrossTalk

Podobně se útok CrossTalk dá využít také k průniku do bezpečné enklávy SGX. Zranitelnost je umocněna tím, že staging buffer údajně obsahuje výsledky i již obsloužené předchozí požadavky i poté, co byly předány jádru, které si je vyžádalo. Díky tomu má škodlivý program o dost lepší možnosti zde šmírovat.

Aktualizace zabrání šmírování, ale zdecimuje výkon RdRand

Tuto zranitelnost Intel opravil aktualizací mikrokódu, přičemž postihuje zřejmě všechny současné procesory až po serverová Cascade Lake – Ice Lake výzkumníci neotestovali, ale nejspíš to u něj bude podobné. Úplná oprava zde asi není takto snadno možná, ale mikrokód nahrazuje chybějící izolaci jader/vláken od sebe tím, že zcela zablokuje sběrnici sloužící pro přístup do staging bufferu do doby, než vrátí patřičnému jádru jeho výsledek, a pak buffer vyprázdní.

Procesory Intel, které byly testovány na chybu CrossTalk Zdroj: VUSec: CrossTalk

Teprve poté je zase přístup do fronty odblokován. Jde tedy o jakési softwarové nahrzení chybějící hardwarové izolace. Díky tomu je možné ochránit tyto operace před odposlechem z jiných jader, ale za cenu promrhání většiny kapacity dané jednotky. Kvůli tvrdému dopadu na výkon je tato ochrana implementována jen pro instrukce kritické pro bezpečnost (RdRand, RdSeed, EgetKey). Výstupy z dalších instrukcí, které se zpracovávají mimo CPU jádro přes staging buffer, například RDMSR, lez pořád odposlouchávat.

Oprava totiž přináší razantní snížení výkonu instrukcí RdRand a RdSeed, podle testu Phoronixu je výkon generátoru náhodných čísel snížený na zlomek původního. Rychlost či propustnost generování náhodných hodnot pomocí instrukce RdRand klesla o 97 %, tj. na 3 % původních schopností. Pokud tedy máte nějaký software, který konzumuje velké množství náhodných čísel z tohoto zdroje, může se projevit propad výkonu. Toto naštěstí nebude mimo server nic běžného.

Chyba CrossTalk: dopad opravy instrukce RdRand Zdroj: Phoronix

Reálně by dopady neměly být velké, a nastanou jen izolovaně

Phoronix při testování ověřil, že aktualizace firmwaru v naprosté většině programů s výkonem nic nedělá, takže jsou zřejmě opravdu ovlivněné jen a pouze instrukce RdRand a RdSeed. Benchmarky Apache, NGINX a DaCapo mohou v celkovém měření přijít o pár procent výkonu. Nejspíš je to dáno tím, že potřebují náhodná čísla pro různé kryptografické účely během komunikace (HTTPS…).

Chyba CrossTalk: dopad opravy instrukce RdRand v reálném softwaru Zdroj: Phoronix

Z tohoto útoku a výkonnostních dopadů si tedy budou muset dělat vrásky uživatelé serverů s procesory Intel. Jde o útok specificky na jejich architekturu – je možné, že něco takového by mohlo paralelně postihovat i jiná CPU třeba od AMD nebo ARMu, ale vývojáři zřejmě nezjišťovali, zda jsou také zranitelná tímto způsobem. Útok by se jim asi musel přepsat na míru. Pro běžného uživatele není asi příliš důvodů ke starostem ani k tomu, bránit se instalaci těchto záplat (tedy této aktualizace mikrokódu).

Aktualizace by již měla být venku; časem by se měla dostat i přímo do BIOSů desek, ale většině uživatelů by ji dříve měla přinést aktualizace prostřednictvím operačního systému – opravy mikrokódu procesorů Intel jsou distribuovány jak přes Windows, tak v Linuxových distribucích.

Galerie: Bezpečnostní chyba CrossTalk v procesorech Intel

Zdroje: Intel, VUSec, CrossTalk (referát s podrobnostmi), TheRegister, Phoronix

Bezpečnostní chyba CrossTalk v procesorech Intel zpomalí programy závislé na RdRand
Ohodnoťte tento článek!
5 (100%) 9 hlas/ů

26 KOMENTÁŘE

  1. Zmínil bych ještě další ránu pro výkon SQL systémů, nejenom WEB serverů – taktéž měřeno v tom samém článku na Phoronix.com.

    xSQL servery jsou právě jedněmi z nejvíce výkonově postižených systémů vlivem různých mitigací Intel zranitelností. Na datacentrech, které v práci spravujeme, se musely dokupovat další boxy a rozšiřovat clustery jen kvůli tomu aby se aspoň dorovnal výkon po mitigacích… bohužel kvůli kompatibilitě opět Intel :/

            • Tak to se hluboce mýlíte. Na prvním místě je byla a bude cena v poměru k vlastnostem a službám. Chyby výrazně snižují tento poměr.

            • Chyby se vyskytuji v jakemkoliv hw a sw, spravci updatuji denne. Dulezite je, aby vendor nenechal klienty na holickach.

            • To: hnizdo. Víte já jsem z té doby kdy intel produkoval procesory prakticky bez chyb. To že si něco takového nepamatujete a vidíte jenom tenhle procesorový marasmus neznamená, že to nebylo zvykem. SW je zcela jiná kategorie. Tady mícháte hrušky a jablka dohromady.
              Navíc v tomto konkrétním případě nechal vendor klienty na holičkách tuším skoro dva roky. To je opravdu nezodpovědné chování kdysi seriózního Intelu.

            • musím připomenout, že na sidechannel chyby se přišlo po více jak deseti letech od vydání postižených architektur, včetně AMD, Armu atd. čili žádné dnes a tehdy.

              Intel na chybách dva roky pracoval po dohodě s objeviteli, čili v žádném případě nenechal nikoho na holičkách. Hovořit o nějaké nezodpovědnosti svědčí o tvé naprosté neznalosti postupu v podobných situacích.

            • jo, mimochodem, treba 9900K rev R0, step. D uz danou zranitelnost nema. To jen k tomu jak dlouho uz na tom intel pracuje.

            • DedekHrib 17.6.2020 at 12:07
              Mozna se mylim, ale me osobni zkusenosti jsou odlisne od toho, co pisete vy.

              hnizdo 17.6.2020 at 18:44
              Vidim to podobne.

            • To: hnizdo a Alich. Pánové víte já jsem psal o mnohem dřívější době. Asi jsem měl být konkrétnější.
              Víte ono mi je 56 let a Vy asi budete mnohem mladší. Psal jsem o době kdy mi v počítači pracoval Intelovský procesor Pentium 3 s 440BX chipsetem. Tehdy byl svět opařen z toho, že pro jeden konkrétní výpočet procesor vykazoval chybu. Tehdy byly procesory od Intelu takřka bezchybné a procesory se značkou AMD pro mne byly šunt který mi nemohl do počítače. Inu časy se mění.

            • AMD CPU nebyly nikdy sunt, naopak mely velmi slusny vykon za podstatne mene penez, ne jako dnes – tehdy byl rozdil v cene nekdy i trojnasobny.
              Co byl priserny sunt a co muze za spatnou povest cele platformy, byly chipsety a motherboardy obecne. Mizerny vykon, drivery, kompatibilita, stabilita. Jednooky mezi slepymi byla VIA a pozdeji Nvidia, ale jinak to byla tragedie. Jeste se mi dneska zda o deskach PCChips s chipsety SiS. V nejhorsich nocnich murach se vraci chipsety Ali.

            • DedekHrib 18.6.2020 at 9:25
              OK, zrovna P3 bylo vyborne. Ja uz jsem treba v teto dobe mel nekde nasazene Durony, protoze cena / vykon byl lepsi, nekde zase vyhradne intel.
              Ja si ale myslim, ze doba neni uplne podstatna, spise zamereni na trhu. Pokud se bavime o resenich pro dodavatele serverovych reseni (Dell, HP, …) + SW firmy, tak samozrejme je support, prima a blizka spoluprace to nejdulezitejsi. Jak jsem psal, chyby byly, jsou a budou (a to i ve starych architekturach) – ted je doba akorat „rychlejsi“.
              Pokud se bavime o trhu pro koncoveho uzivatele – hry / kancelarska prace / internet / DTP / animace / video / … tak tam zase tyto chyby v CPU *vetsinou* nemaji velky dopad. Protoze bud je chyba velmi tezko az vubec zneuzitelna, nebo fix neprinasi penalizaci vykonu. U serveru je to samozrejme jina pohadka.

            • to: hnizdo No a právě to je to. protože bez desky je procesor k ničemu tak pro mne řešení AMD bylo šuntem co mi nesměl do počítače. Jinak ale je fakt, že ti pánové co dělali u DEC Alphy to prostě uměli dělat.

            • No myslím, že tyhle vzpomínky můžou být dost přehnané, takhle černobílé to nebylo. Často přesně tyhle slova „Co byl priserny sunt a co muze za spatnou povest cele platformy, byly chipsety a motherboardy obecne. Mizerny vykon, drivery, kompatibilita, stabilita.“ se tehdá tradovaly v diskuzích na webu, slovo od slova. A stačí se podívat na dnešní diskuze a je jasný, že neodráží tak úplně to, jak to vypadá v praxi. Viz třeba komentáře extrémně zveličující „děravost“ Intelů.

              V 2004 až nevím, 2010 jsem měl desku s čipsetem VIA KT600 s Ahtlonem XP 2200+ a bylo to 100% stabilní a pohodový (A7V600-X, jen kdybych v tom kompu měl víc RAM…).
              Pak od 2005 nForce4 Ultra + Athlon 64 3200+. Ten čipset Nvidia měl bugy, ale když se vypnuly nefunkční fíčury („HW firewall“) tak zase 100% stabilní. Pravda, tam byla ještě nekompatibilita s HDD, což byl teda velký průšvih NForce, ale tomu jsem se vyhnul díky tomu, že jsem měl disk Seagate. S touhle výradou 100% stabilita (oba kompy měly nějaký levný Radeon jako grafiku). Je pravda, že jsem zase minul dobu s můstkem Via 686B, kde se IIRC mluvilo o dost velkých problémech.

              Jinak ty čipsety VIA a SiS nebo ALi (a pak i Nvidia) se úplně stejně používaly na platformě Intel, když měl člověk levné PC, tak to mohla být právě deska s tímhle. Třeba PIII Celeron jsem měl na desce s VIA Apollo Pro 133, kde tehdy padaly některé hry (s Nvidia Riva TNT2…), ale tam si nejsem jistý, jestli to nemohly dělat ovladače pro Windows 98 nebo podobný problém.

            • Nic se netradovalo ani nezvelicovalo. Byla to pravda, moje dennodeni praxe, tehdy 60 kompu a serveru XP/95/98/NT4. VIA byla sice stabilni, ale mela nizky vykon IDE a sbernic obecne, a kompatibilita byla tez omezena. Rozjet nektere GPU, zvukarny nebo dokonce radice bylo peklo. A ty same problemy mely tyto chipsety s intel CPU, jenze tam byly nastesti k dispozici originaly.