Nagyjából egy hete számoltunk be arról, hogy az OpenBSD biztonsági szempontból letiltja a Hyper-Threadinget az Intel processzorokon, de akkor csak egészen általános magyarázatot szolgáltattak a fejlesztők, amiből arra lehetett következtetni, hogy semmiféle probléma nincs a háttérben, csak bizonyos potenciális támadási felületeket akarnak teljesen lezárni.
Nemrég azonban egy Amszterdamban található egyetem (Vrije Universiteit Amsterdam) kutatócsoportja előállt egy olyan állítással, hogy 99,8%-os hatékonysággal tudták ellopni a Curve 25519 EdDSA kriptográfiai algoritmus 256 bites titkosítási kulcsát egy Core i7-6700K processzoron, de hasonló eredmények jöttek más Hyper-Threadinggel rendelkező Intel processzorokon is, maga az adatlopás pedig fél percen belül megvalósítható, bár a pontos folyamatát nem részletezték.
A támadás alapját az adja, hogy Hyper-Threadinggel rendelkező magokon kvázi egyszerre, pontosabban egymást váltva futhat két programszál, amelyek a magon belül a legtöbb erőforrást megosztják egymással, ideértve a TLB-t, azaz Translation Look-aside Buffert is, ahol tárolva vannak a címfordítás felgyorsítása érdekében a tényleges memóriacím kiszámításához szükséges adatok. Utóbbi egy nagyon hasznos dolog, mivel a virtuális memória jóval nagyobb a fizikainál, és ezáltal a virtuális memóriacímek nem egyeznek a fizikaival. Vagyis ahhoz, hogy egy program elérje a fizikai memóriában tárolt adatot, előbb le kell fordítani az adott virtuális címet fizikaira. Az egész egy igen nagy adatstruktúra, amit az operációs rendszer kezel, ugyanakkor nem célszerű, ha minden egyes memóriaelérés esetében meg kell keresni az adott virtuális cím fizikai megfelelőjét, így a TLB egyfajta gyorsítótárként funkcionál, ami tárolja az erre vonatkozó legfrissebb adatokat, és esetenként nem kell az operációs rendszer címfordításához folyamodni, mert a szükséges adat ott van a TLB-ben.
A fentiek önmagukban nagyon jók, de Hyper-Threading lehetővé teszi az egyik szálon futtatott programnak, hogy figyelje a másik szálon futó alkalmazás működését, kiemelve TLB új bejegyzésekkel való feltöltését, és ez gyakorlatilag manipulálható úgy, hogy végeredménybe a támadó célzattal futó szál bizonyos adatokat kilopjon a memóriából.
A TLBleed nevű biztonsági rés súlyosságáról megoszlanak a vélemények. Az biztos, hogy nem akkora a gond, mint mondjuk a Spectre esetében, hiszen eddig is voltak olyan támadásminták, amelyekkel el lehetett érni hasonló eredményt, így általánosnak számít a kriptográfiai algoritmusok tekintetében, hogy az implementáció szempontjából az adatszivárgás lehetőségét minimalizálják. Az Intel is azzal védekezik, hogy a saját kriptográfiai megoldásaik védettek a TLBleed ellen, így a vállat nem is fizet a biztonsági rés felfedezőinek, ami végül CVE bejegyzést sem kap, vagyis végeredményben általános javítás sem várható rá. Az egyetlen lehetőséges védekezési mód a különböző gyorsítótárat védő eljárások beépítése a programokba, így nehezítve meg a TLBleedhez hasonló támadások véghez vitelét.
Ami viszont aggasztó lehet, hogy a TLBleed megjelenéséig számos kriptográfiai algoritmus biztonságosnak számított, de mától lényegében már nem azok, tehát a gond nem is annyira jelentéktelen, ahogy azt az Intel lefesti. Ilyen formában egyéni döntés kérdése, hogy a TLBleed mennyire tekinthető súlyosnak, az OpenBSD fejlesztői például annyira annak tartja, hogy letiltották a Hyper-Threadinget, és lehet, hogy mások is hasonló irányba mennek majd el.
Az Intel szemében ez nem járható út, elvégre a Hyper-Threadinggel rendelkező processzoraik elvesztenék a feldolgozási szálaik felét, vagyis olyan megoldásokat fognak erőltetni, amelyekkel a funkciót életben tarthatják. Ez gyakorlatilag a biztonságosabb programozásra való buzdításból fog állni, másképp nem igazán lehet az ilyen támadások ellen védekezni. Ennek megfelelően a vállalat valószínűleg megpróbálja segíteni az érintett kriptográfiai megoldásokat szoftveres frissítését.
Megjegyzendő, hogy az AMD már jelezte, az SMT-t használó processzoraikat megvizsgálták a TLBleed szempontjából, és nem találtak olyan modellt, amely érzékeny lenne a támadásmintára. Más, szintén szimultán többszálúságot alkalmazó processzorgyártó még nem reagált a fejleményekre.
