Hlavní navigace

Vlákno názorů k článku Procesory Intel mají vážnou hardwarovou chybu, záplata výrazně snižuje výkon od snajpa - Tyka se i AMD, i ARMu. https://googleprojectzero.blogspot.cz/2018/01/reading-privileged-memory-with-side.html

  • Článek je starý, nové názory již nelze přidávat.
  • 4. 1. 2018 0:48

    Petr Soukup

    Podle diskuze pod článkem na který odkazujete v praxi má problém jen Intel.
    Bug mají všichni, ale v praxi nebezpečný problém má jen Intel. Doufám, že se z toho nijak nevyvlíkne a schytá ostudu a výrazný propad akcií.

    Třeba:


    So for AMD, this appears to only impact Linux and FreeBSD users using an "APU" who've manually turned on the BPF JIT. Considering I had no clue this thing existed until now, I'm going to guess this impacts all of 3 users.

    https://www.kernel.org/doc/Documentation/networking/filter.txt

  • 4. 1. 2018 1:04

    snajpa (neregistrovaný)

    Mne staci videt v clanku napsane, ze autori maji working proof of concept pro vic architektur. Polepit to s par nakoupenymi zero-days na ziskani user level privs... Kdo vi kde je az meze mozne spionaze/kompro­mitace vseho mozneho. Staci dost motivace. Vsechno ostatni se da dohledat a doucit vcelku rychle, pokud clovek ma nejaky solidnejsi zaklad.

  • 4. 1. 2018 9:43

    654 (neregistrovaný)

    Jde o tři zranitelnosti:

    - Bounds Check Bypass
    - Branch Target Injection
    - Rogue Data Cache Load

    AMD je imunní proti třetímu, u druhého je téměř nulová šance na provedení útoku (ještě se to nikomu nepodařilo) a je reálně napadnutelný pouze tím prvním, který jde záplatovat bez změny architektury procesoru.

    Intel je napadnutelný všemi třemi. To je cena za mírné zvýšení výkonu, a není to poprvé. Například vlastnost "inclusive cache" a sdílení L3 cache všemi jádry u intelu umožnila pěkně nechutný side-channel útok a získání šifrovacího klíče, a to i mezi virtuálními OS (útok flush+reload; úspěšnost byla průměrně 96,7% bitů 256-bitového klíče z pozorování pouze jedné šifrovací operace).

  • 4. 1. 2018 21:45

    ventYl

    Este je dobre dodat, ze zjavne jedine treti utok je mozne vykonat bez sucinnosti toho, na koho sa utoci (trebars kernel). Z toho vyplyva implikacia, ze prvy a druhy utok budu mat dopad sirsi nez len jadro OS ale prevedenie utoku bude o to tazsie, ze bude nutne najst ovela spolahlivejsi side-channel na prepasovanie tajnej informacie a rychlost utoku moze byt obmedzena tym, ze na to aby bol utok uspesny je nutne obet prinutit k sucinnosti.

    To, ake lahke je obet prinutit k sucinnosti zalezi od toho o co sa jedna. Pri programoch, ktore obsahuju JIT alebo potencialne zranitelne konstrukty v kode spustitelne zvonku to moze byt relativne lahke, pre ostatny software to moze byt oriesok.

    O tejto triede utokov este urcite budeme pocut a je mozne, ze aj buffer overflowom to doda uplne iny novy rozmer. Je totiz pravdepodobne, ze triedy bezpecnostnych problemov, ktore doteraz napr. neboli zaujimave (out of bounds pristup k prilis malej pamati nez aby do nej slo narvat zaujimavy payload) sa zrazu mozu stat zneuzitelne tym ako sa budu sledovat ich podprahove side-efekty.

  • 5. 1. 2018 12:01

    jdsulin2 (neregistrovaný)

    Neresi to nahodou pres ten JIT kompilovany BPF ? Myslim tu injektaz potencionalne nachylneho kodu ? Druha vec je, ze teoreticky staci nejaka posloupnost instrukci a hledej pak v celem jadru a kodu takovou vec.

  • 5. 1. 2018 17:24

    ventYl

    Ano, riesi sa to cez JIT a kompilovany eBPF. Je dokonca mozne, ze ten kod na to nie je ani treba vykonat, staci aby sa zacal prekladat. Prekladace su pomerne vdacny ciel na takyto typ utokov.

    S tou postupnostou instrukcii je to trocha problem. KASLR zamedzuje tomu, aby clovek sfleku vedel urcit adresu kodu v pamati. Navyse, na to aby slo otravit branch target buffer by musel byt proces schopny nieco namapovat na virtualnu adresu, ktora v inom procese prislusi kernelu a to vo vseobecnosti nejde.

    Takze jediny sposob, akym mozno tymto utocit voci jadru je poslat vstup, ktory otravi branch prediktor do vhodneho vetvenia (idealne jump-table) v kode jadra.

    Na druhu stranu voci aplikaciam mozno utocit trivialne jednoducho a bude celkom zaujimave sledovat, co vsetko sa tymto sposobom podari odhalit. Riesenie tohto problemu si vyziada od kernelu minimalne to, aby umoznil / sposobil pri prepnuti tasku vymazanie bufferov branch prediktora. Ale to nevylucuje, ze sa nenajde v buducnosti iny sposob, ktorym mozno "na dialku" procesor takto nechutne osalit.

  • 7. 1. 2018 15:58

    jdsulin2 (neregistrovaný)

    S tim otravenim mi to taky neprijde uplne tezke. Proste ten vygenerovany kod budes volat s validni adresou nekolikrat a pak mu tam posles jednou nevalidni. Ale nvm no, takhle bych si to predstavoval teoreticky, jestli to bude fungovat, netusim.

  • 8. 1. 2018 10:38

    ventYl

    Nie, nie. To su dva rozne vektory utoku. Ked sa otravuje branch target buffer, tak sa procesor pocas behu procesu A presvedci, ze je vysoko pravdepodobne, ze podmieneny skok na adrese X skoci na adresu Y. To sa docieli tak, ze v utocnikovom procese sa naaranzuje situacia tak, ze sa vykona vela skokov z virtualnej adresy X na virtualnu adresu Y. po prepnuti procesov sa obet utoku dopocita k virtualnej adrese X a procesor na zaklade predpovede branch target buffer zacne spekulativne vykonavat kod na adrese Y kam povodny kod vobec nemusi chciet / moct skocit. Utocnicky proces potom preskuma sideefekt toho spekulativneho vykonania kodu.

    Tento problem je:
    a) obmedzeny na procesory Intel rovnako ako utok meltdown. Teoreticky by asi fungoval aj na AMD, ale nejake drobne architektonicke rozdiely (inac fungujuci BTB?) sposobuju, ze ten utok nejde replikovat.
    b) typicky nie je mozne vyuzit voci kernelu, pretoze userspacovy proces spravidla nie je schopny kontrolovat kod na virtualnych adresach prislusiacich kernelu.
    c) vzhladom k tomu, ze BTB nie je zdielany zdroj, utociaci proces aj obet utoku musia byt vykonavane na rovnakom jadre.

    Druhym vektorom utoku je proste a jednoduche zneuzitie toho ako funguje branch prediktor. Na tento typ zranitelnosti v podstate trpia vsetky procesory, ktore spekulativne vykonavanie instrukcii robia. Tam ide o to, ze sa do nejakeho (typicky) cyklu posle taky vstup, ktory sposobi, ze po istom pocte cyklov bude branch predictor skalopevne presvedceny o tom, ze prebehne nejaka vetva programu. A v tom momente sa do programu zavedie taky vstup, ktory sposobi, ze ta vetva programu opat spekulativne vykona nejake instrukcie, ktorych sideefekt je preskumatelny utociacim procesom. Tento utok je mozne aplikovat aj voci kernelu, avsak v takom pripade je nutne najst vhodny kus kodu (dlhy switch, vela kaskadovych if-else a podobne) alebo JIT, ktory nieco take generuje a zaroven ten kus kodu musi byt ochotny nejaky taky vstup spracovat.

    Analogiou tohto utoku je nasledujuci mindfuck: ruzova elektricka ma ruzove kolesa, ruzovu skrinu, ruzove pantografy, ruzove svetla, ruzovu podlahu aj strechu. Akej farby je na ruzovej elektricke vyfuk?