Bezpečnostní problém L1 Terminal Fault aneb L1TF v procesorech Intel (diskuse)

[Ladislav Hagara]

Další info: Red Hat, SUSE, Ubuntu, ...

[i2041826]

Gentoo

[NN]

Ma patch nejake vykonostni dopady?

[BathSK]

Ahojte,

zial ma, minimalne zrejme chybna aplikacia Linux patchu - neviem, ale dnes rano to zhodilo produkciu, nakolko isla nepouzitelne pomaly. Ide o kernel v Ubuntu 14.04LTS, 3.13.0-155-generic z 10. augusta. Po nabootovani do starsieho kernelu vsetko OK, rovnake spravanie na 3 nodoch. Zaujimave, ze patch v Ubuntu 16.04 kernel 4.4.0-133-generic #159 takisto z 10.augusta je OK.

Pre info - keby mal niekto vykonnoste problemy po aplikovani patchu v Ubuntu.

[BathSK]

tak uz je problem s kernelom 3.13 v Ubuntu 14.04 aj oficialny: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/L1TF vid: * Regression note we are currently tracking two possible regressions for the 3.13 kernel. This note will be updated as more information becomes available. (Bug 1787127 Bug 1787258)

[kralyk z abclinuxu]

Intel má dobrej rok...

[Jendа]

Ostatní výrobce procesorů to asi taky čeká (a některé z těch chyb už se umí aplikovat i na ně). Například AMD se chlubila, že v Ryzenech používají pro branch prediction perceptrony, což podle mě musí být úplně zlatý důl pro podobné útoky.

[kralyk z abclinuxu]

Například AMD se chlubila, že v Ryzenech používají pro branch prediction perceptrony, což podle mě musí být úplně zlatý důl pro podobné útoky.

Nejsem odporník, ale to mi zní jako ortogonální záležitost. Není celkom jedno, jak moc Chytře™ se prediktor rozhoduje? Důležité je, aby netrefující se rozhodnutí neměly side-effecty, to je celé, ne?

Nebo snad protéká mezi procesy/doménami/atd. i stav prediktoru?

[Jendа]

Důležité je, aby netrefující se rozhodnutí neměly side-effecty, to je celé, ne?

Ale prediktor má z principu side effect - když se trefí, tak se instrukce vykonají rychleji.

[Michal Kubeček]

U těch chyb nešlo o to, jestli se prediktor trefí nebo ne, naopak, útok byl postaven tak, aby se zcela určitě netrefil a příslušné instrukce se provedly pouze spekulativně (protože naostro by neprošly).

[kralyk z abclinuxu]

Ale prediktor má z principu side effect - když se trefí, tak se instrukce vykonají rychleji.

Ano, ale zrovna tenhle efekt je viditelný jen tím kódem, kterého se týká.

[Jendа]

Nebo útočníkem, který s tím kódem interaguje a vidí, za jak dlouho dostal výsledek.

[kralyk z abclinuxu]

Ok, nicméně to je timing attack, to je jiný problém. (A skoro bych se divil, kdyby bylo možné ho zneužít bez lokálního přístupu na daný stroj.)

[Cabrón]

To je právě díky klesající latenci a jitteru moderních sítí jedno z nejaktivnějších odvětví bezpečnostního výzkumu. Např. nedávno zveřejněný NetSpectre je perfektním příkladem, jak provést timing attack na pranch predictor přes LAN.

https://misc0110.net/web/files/netspectre.pdf

[kralyk z abclinuxu]

To je zajímavý paper, nicméně to není timing attack na branch predictor, nýbrž timing attack na cache (stejně jako u Spectre atd.) a na AVX2 unit (což je zřejmě další nově objevený side-channel, zajímavé). Je trochu znepokojující, že Spectre se dá využít i takhle přes síť. U toho AVX2 mi to až tak znepokojující nepřijde, protože IMHO v reálné situaci by bylo náročné najít na to v cílovém stroji použitelné gadgety (ale to je pouze můj amatérský odhad, kdoví, možná síťové aplikace zuřivě používají AVX2).

[Jan Kundrát (jkt)]

Ano, AVX instrukce se pouzivaji napr. pri validaci a prevodu mezi ruznymi variantami UTF.

[Jendа]

Já bych hlavně čekal, že přes ně budou akcelerované výpočty s velkými celými čísly (a tedy asymetrická kryptografie).

[Jendа]

Timing útoky se běžně dělaly na kryptografické funkce, které potřebuješ, aby běžely v konstantní čase nezávisle na datech, protože jinak leakují informace o klíči/cizí komunikaci. Například chytrý predictor by mohl zjistit, že je zbytečné po selhané kontrole paddingu pokračovat když funkce stejně vrátí nějaké false, a nechtěně tak vytvořit padding oracle. Na Wikipedii je několik dalších ukázek.

[kralyk z abclinuxu]

Ale jo, já vím o co jde (kdysi jsme i ve škole psali cvičný timing attack proti snadno meřitelnému kódu, byl to triviální případ na seznámení s problémem). Šlo mi o to, že tohle není nijak specifické pro branch predictor, resp. konstantní čas vykonávání musíš zajistit celkem bez ohledu na to, jak je/není chytrej. IMHO stejně všichni považují branch preditkor za arbitrární magii a stadardní postup je prostě vůbec nebranchovat na základě tajných dat, používat místo toho aritmeticko-logické operace, cmov a podobně...

Supr by bylo, kdyby insturkční sady poskytovaly funkce pro vykonávání kódu v konstatním čase (a ideálně ještě taky za konstantní spotřeby energie, produkovaného záření, atd.). Znáš movfuscator? Ten kód poběží asi v celkem konstantním čase z hlediska vykonávání (ale asi už ne z hlediska paměti). Problém je, že nic z toho není AFAIK kodifikované ve specifikaci, myslimže ani časová konstantnost cmov ...

[Michal Kubeček]

Základní problém u většiny těch chyb byl v předpokladu, že se při spekulativním provádění můžeme vykašlat na některé kontroly, protože je přece stačí provést až když budeme vědět, že se ta větev bude opravdu provádět. Bohužel si neuvědomili, že už to spekulativní provedení může mít zneužitelný side effect. Interní informace samozřejmě nejsou, ale zatím se zdá, že u AMD tuhle "zkratku" nepoužili, ať už proto, že si uvědomili rizika, nebo proto, že nechtěli algoritmus komplikovat.

[little.owl]

což podle mě musí být úplně zlatý důl pro podobné útoky.

To jsou spekulace. Branch prediction se vsech vykonnejsich procesoru uci a pouziti perceptronu je jen jiny pristup, ktery neni zatim prokazatelne zranitelnejsi, nez jine pristupy, spise naopak nebot je tezsi ho simulovat. Pokud jde o L1TF, AMD je touto chybou v Linuxu nedotcena.