Názory k článku Útok TLBleed na procesory Intel ohrožuje šifrovací klíče pomocí Hyper-Threadingu
-
unicode (neregistrovaný)
To s tím HT jen pro stejný proces taky není tak úplně jednoduché, přímo od Raadt:
"Let's say you just run threads of the same program, so they have the same address space. One of the threads does a system call, so it is now running in the kernel. In a subtle way, the rule has just been broken."
-
Peter FodrekZlatý podporovatelTo sa síce dá jednoducho a elegantne riešiť, ale bude to stáť kopu výkonu.
V RTLinuxPro delili CPU/jadrá na jadrá pre Realtime a non=reltime úlohy., Tu by mohli byť jadrá na ktorých beží len kernel a jadrá na ktorých beží len userspace. A teda pri prepínaní ringu by sa vlákno presunulo na iné jadro, Aj keď si uvedomujem cenu na výkone, bezpečnosť by to zvýšilo...
RTLinuxPro CPU reservation technology
May 7, 2004http://linuxdevices.io/rtlinuxpro-cpu-reservation-technology/
-
Peter FodrekZlatý podporovatel
Aby nedošlo k nedorozumeniu
Uvedomujem si, že v mojom riešení bude "skákať krava"4 March 2013
There's also a scheduler patch to fix a "bouncing cow" problem by when running fewer processes on the system than number of processor cores, the process could be bounced around between cores and yield poor performance. This bouncing cow fix for the scheduler yields a performance boost by 15x in a worst-case scenario. More work will come to future Linux kernel releases.https://www.phoronix.com/scan.php?page=news_item&px=MTMxNzA
February 20, 2013
https://lwn.net/Articles/538101/ -
x (neregistrovaný)
Aneb neco co ma treba NetBSD a mel to davno Solaris nebo HP-UX? http://netbsd.gw.com/cgi-bin/man-cgi?psrset+8
-
Peter FodrekZlatý podporovatel
To, j e príliš málo na to, o čom píšem, ale povedzme to, čo píšete je dobrý základ, akurát robí len s user space úlohámi a nie s kernel úlohami aj uiser space úlohami, čo potrebujem ja....
-
Co to furt někdo používá za novotvary? https://cestina20.cz/slovnik/souvis/ :-D
-
Peter FodrekZlatý podporovatel
Vrije je holandsky slobodný/á/é
Takže vo Vašom výklade Univertzita bez AMD
-
kantor (neregistrovaný)
asi nejste z IT, ze?
nez se spusti jakykoliv projekt, musi se naplanovat na zaklade predpokladu ... :-D
a dukazy? to je faze testovaci: kdyz neprojdou testy, nejsou dukazy.
ale to vubec nevadi, protoze se vyhlasi, ze za to muzou testeri :)i kdyz byl pouzit termin 'pomerne' - takze vlastne jo, je to pravda. jde o ten pomer exaktnosti a predpokladu.
-
Peter FodrekZlatý podporovatel
Ale to podstatné ste vynechali.
"
1. (AMD) Používají totiž velmi podobný mechanismus umožňující běh více nezávislých vláken na jednom jádře.To také komplikuje ochranu aplikací před tímto typem útoku, protože
2. správně napsaný program může odolávat na jedné architektuře, ale mírně odlišná architektura (i stejného výrobce) může znamenat problém.
"
Ale, otázkami zostávaA. Ako veľmi podobný/odlišný je spôsob AMD?
B. Nie je práve tá malá odlišnosť tým, čo AMD chráni (možno len proti väčšine) útokov... -
V článku mi chybí popis, jak TLBleed proces zajistí, aby běžel na správném virtuálním HT jádře konkrétního fyzického jádra, na jehož druhém virtuálním HT jádře běží proces, kterému chce zcizit data a jak zajistí, že proces jeho zájmu tam poběží dostatečně dlouho, aby měl čas svou záškodnickou činnost vykonat, protože ten může svou práci mezitím dokončit (např. webový server jak je zmíněno v článku, který mezitím obsloužil konkrétního klienta) a "uteče" pro další běh na jiné jádro.
-
dizzy (neregistrovaný)
no to by nemusel byt zase az taky neprekonatelny problem - ked spustis dostatocny pocet vlakien (viac nez jadier), tak je statisticky dost pravdepodobne, ze jedno z tych vlakien sa ocitne "hned vedla" procesu, ktory nas zaujima...
Kazdopadne cim viac vlakien spustis, tym vacsia sanca, ze si tvoj proces niekto vsimne ;-) -
Já netvrdil, že to je nepřekonatelný problém, já jen psal, že mi to v článku chybí. Nicméně úplně jednoduché to nebude, viz váš vlastní příspěvek...
Zatím mi to přijde, že jim to funguje dobře v laboratorních podmínkách, v běžném provozu by se úspěšnost 100% asi neblížila. Ale možná se pletu. Prostě to v článku chybí. -
Petr M (neregistrovaný)
Máš stroj, 16 jader fyzických, 32 logických. Připojí se ti současně řekněme 60 klientů po HTTPS, pro každýho server vytvoří vlastní vlákno ne odbavení požadavků, který má v náplni práce i šifrování. Jaká je pravděpodobnost, že na některým z těch 16 jader pojede vlákno, který používá šifrovací klíč toho serveru?
Stačí číhat a analyzovat provoz. Až zjistí, že na jádře běží něco, co šifruje,...
Otázka je, jak zajistit, že se na (veřejný web server) připojí několikanásobně víc klientů, než má ten server jader... Ale spustit si na jednom stroji (nebo několika virtuálech) několikrát wget je docela triviální věc.
-
To je hodně zjednodušené... Na takové serveru poběží daleko více úloh, než jen web server s HTTPS, ale také připojování do DB, I/O a kdo ví co ještě.
Každopádně souhlasím s tím (jak píšu jinde v tomto vlákně), že když poběží delší dobu, je jisté, že se k nějakým užitečným datům dostane. Neobhajuji Intel a jeho HT, jen se více zajímám o tento typ útoku. -
Přinejmenším není problém udělat spršku dotazů po HTTPS a doufat, že se to u jednoho z nich potká. To může i za celkem krátkou dobu.
Podobně by šlo útočit i na klienta, možná trochu krkolomněji:
1. Oběť si načte example.com přes plain HTTP. To mě sice nezajímá, ale mohu tam vložit svůj skript.
2. Skript spustí měření side channelu, ideálně ve WebWorkers.
3. Skript udělá spršku požadavků na https://foo.com. Cross domain policy tomu nezabrání, lze použít třeba <img>.Na klientovi sice obvykle není privátní klíč, ale k ukradení jedné session a přečtení cookie nebo otrávení cache to stačit může.
-
Zkusím hádat:
* Útok byl prvně proveden v laboratorních podmínkách, kde toto prostě zajistili. V reálných podmínkách se to na první pokud nepodaří, za chvíli to bude mít úspěšnost 10 % a během roku to vyroste třeba na 50 %. A s nižším úspěchem brzy i z JS v prohlížeči. Ono i 1% šance na úspěch je celkem dost, zvlášť pokud útočník může útok opakovat.
* Ta šance není malá, přecejen nemáme až tolik vláken.
* Trochu problém může být, že se chytrý plánovač bude snažit obsadit fyzická vlákna rovnoměrně, čistě kvůli výkonu.
* Mohu spustit více útočných vláken.
* Útok je celkem rychlý, takže je celkem málo pravděpodobné, že se v průběhu útoku oběť nebo útočník přestěhuje jinam.
* Co vím, tak plánovač se snaží úlohy typicky držet nějakou dobu na jednom jádře. -
V tom máme asi hodně podobný názor... Logicky čím více procesů, čím více jader, čím inteligentnější plánovač tím to má záškodnický kód složitější.
Zas tak rychlý mi ten útok nepřipadá. První fáze trvá 2 ms, kolik cyklů u 4 GHz CPU za tu dobu proběhne se dá snadno spočítat.
Spuštěním více vláken se útočník IMO velmi snadno prozradí a má po žížalkách. Na druhou stranu je fakt, že záškodnický proces může sbírat data dlouhodobě a nějaká užitečná data po čase určitě vykutá.
Každopádně jsem zvědavý na další detaily, protože když přišel Intel s HT, tak to byla jedna z prvních věcí která mě napadla - jak moc dobře jsou chráněna data na jednotlivých virtuálních jádrech proti jinému procesu běžícímu na stejném fyzickém jádře. Dnes už víme jistě, že špatně... Otázka také je jak to má AMD, jak moc tomu pomůže schopnost šifrovat paměť atd. No bude to zajímavé sledovat... -
> První fáze trvá 2 ms, kolik cyklů u 4 GHz CPU za tu dobu proběhne se dá snadno spočítat.
Jenže, co jsem kdysi od oka pozoroval, když vytížím jedno jádro jedním procesem a ostatní jsou v klidu, trvá třeba 15s (od oka) než se úloha přesune na jiné jádro. To je proti několika ms dost dlouhá doba. (Nejspíš bude záviset i na teplotách jednotlivých jader a dalších faktorech.)
> Spuštěním více vláken se útočník IMO velmi snadno prozradí a má po žížalkách.
Dost záleží. Pokud se bude snažit je mít spuštěné 24/7, tak možná jo. (A ani to není jisté – kdo to bude řešit v cloudu?) Pokud je inteligentně spustí, když je to relevantní, uvidíme třeba pár malých spiků za den – kdo to bude řešit? A někdy (vlastně asi celkem často) je možné oběť „vyprovokovat“ k nějaké kryptografické operaci, pak nemusíme hledat vhodnou příležitost.
> jak moc tomu pomůže schopnost šifrovat paměť
Dost pochybuju, že to pomůže proti tomuto útoku.
-
Protože Intel tlačil na to, aby to běhalo rychle (a to už od dob Pentia, které špatně počítalo ve FP, ale zato rychle :D), ne aby to běhalo správně a podle toho to teď vypadá. Samé Meltdown, Spectre, teď TLBleed... Kolik výkonu Intel ztrácí, když se to zazáplatuje? Pokud si vzpomínám dobře, v době AMD FX tuším ztrácelo na Intel cca 30 %, na druhou stranu dnes víme, že např. na Meltdown netrpí, takže pravděpodobná příčina ztráty výkonu AMD je nasnadě. S HT to vidím podobně. Možná to je důvod, proč SMT AMD nasazuje až teď, kdo ví.
-
Detaily nevím, ale pochopil jsem to tak, že se zneužívá spíše memory access pattern, na což šifrování moc nepomůže.
Záleží taky na detailech toho šifrování:
* Některé módy vyžadují přečíst více dat (celý blok), ale to asi nebude případ šifrování v RAM, podepsalo by se to dost na výkonu.
* Pokud šifrování funguje dostatečně transparentně, těžko to pomůže čemukoliv kromě cold boot attacku. -
Petr M (neregistrovaný)
Ony jsou i zařízení například do USB, který dokážou vygenerovat sadu klíčů, privátní se nedá vyčíst a operace s ním se dělají tak, že se zapíše soubor do něj (např. standardní mass storage) a přečte se zpátky zašifrovaný/rozšifrovaný. Veřejný klíč je tam normálně dostupný.
Tam samo takový útok nemá smysl. Tam bych spíš šel po řadičích USB, než po CPU.
-
Krypto (neregistrovaný)
Obe, ktere se s privatnim klicem obvykle delaji: podepsani a desifrovani zpravy. Token vam nikdy privatni klic neda, ale na pozadani s nim tyhle operace udela. Takhle funguji vsechny tokeny i HSM moduly. Poslete jim zpravu, pak zadate treba na PIN padu heslo a vrati se vam vysledek. Klic v pameti pocitace nikdy neni, nikdy ho neuvidite.
-
Krypto (neregistrovaný)
Privatni klic se vygeneruje na externim zarizeni (token, smart karta, HSM...) a nikdy ho neopusti. Nedostane se do pameti pocitace, procesor s nim nepracuje. Nikdo ho z toho zarizeni nedostane. Pokud ho chces pouzit, musis zpravu predat tomu zarizeni a to na ni operaci samo provede. Zarizeni je pripojene pomoci nejake linky, USB, PCI Express, NFC, Bluetooth a podobne. Prave proto se tyhle moduly pouzivaji, protoze zadna hardwarova ani softwarova chyba v PC neohrozi privatni klice.
-
xxxxx (neregistrovaný)
@Kentan z Montargi
Představ si to tak (a není to daleko od pravdy), že přes to USB se pošle nějaký text do jiného počítače. Ten jiný počítač je ten dongle. Má svůj procesor, svou vnitřní paměť, ... a nic z toho není přístupné (přes USB). Jediné, co tam po USB, běhá, je text který chceš (de)cryptovat. Putuje jednou tam a jednou zpět (upravený). Privátní části klíče nikdy neopustí ten dongle pčítač.Tam není šance se dovnitř dostat ... jedině pokud by byl bug uvnitř toho dongle počítač a musel bys na to napsat speciální útok (na nějaký známý bug - ale žádné známé nejsou) ale to je jiná otázka (a navíc je ten dobgle počítač celkem jednoduchý, takže není tolik prostoru pro chyby)
-
lol2 (neregistrovaný)
Taky USB kluc ma exposnute API. Ty mu posles PIN a string ktory chces hashnut. Ked je PIN spravny, tak si zariadenie otvori storage kde je private key a tym zahashuje string a vrati ti ho. Tieto zariadenia maju vlastny procesor, takze netreba pouzivat procesor z pocitaca. A ku storage v USB zariadeni nie je ziaden priamy pristup z vonku, ma k nemu access len procesor na zariadeni.
-
Petr M (neregistrovaný)
Ne hash, ale crypt/decrypt.
Hash je jenom schování zprávy do jednoho čísla definované délky s tím, že nejde zprávu dostat nazpět. A to můžeš udělat kdekoliv bez prozrazení tajemství*. Resp. pokud něco hashuješ, máš to v paměti v surovým stavu a nepotřebuješ tajemství.
* - pokud neděláš hash z kombinace zpráva + sůl + klíč
-
AES ani RSA nejsou hashe. Hash je jednosměrný, pokud útočník není schopen odhadnout preimage. To se může stát, pokud je málo variant (například útočník ví, že jde buď o hash z „ano“, nebo z „ne“), případně některá z variant je dostatečně pravděpodobná (například heslo „123456“ nebo heslo shodné s nickem). Pak útočník může zkusit svůj tip a ověřit, zda se trefil.
-
null null (neregistrovaný)
@ByCzech
Já netvrdil že to jde nebo nejde, ani že jsem odborník na Krypto tokeny. Ty jsi sem zatahl Kryptotokeny o kterých evidentně víš že to mu nepodléhají a máváš pojmy jako "paměť", ale nejsi schopný říct kterou máš na mysli nebo jak je ten token manipulován - zhomotnit se asi nějak nezhmotní a cest jak ho používat bude evidentně více, třeba jak to psal @Petr M.
Takže jaký je vlastně význam tohoto cvičení? Proč si hraješ na to, že se na to "ptáš" ? -
x (neregistrovaný)
Cas na pripomenuti klasiky a historie.......
https://web.archive.org/web/20111219103039/http://hysteria.sk:80/prielom/25/#vid
