Új Spectre-változatot azonosítottak kutatók, amely azt használja ki, ahogyan a processzorok megjegyzik a dinamikusan generált kód helyét. A vizsgálatban érzékeny Linux-memóriát sikerült kiolvasni olyan konfigurációban is, ahol a korábbi spekulatív végrehajtási támadások elleni védelmek be voltak kapcsolva.
A Branch Target Reuse, röviden BTR nevű módszer a futásidejű, úgynevezett just-in-time, vagyis JIT-fordítást célozza. Ezt a böngészők, programnyelvi futtatókörnyezetek és a Linux kernel egyes részei arra használják, hogy a program működése közben alakítsák a kódot gépi utasításokká.
A kutatás központi megállapítása szerint a végrehajtható kód lecserélése nem feltétlenül törli a processzor korábbi előrejelzéseit arról, hol kezdődött az eredeti kód.
A VUSec és a Scuola Superiore Sant’Anna kutatói a Linux klasszikus Berkeley Packet Filterét, a Firefox SpiderMonkey motorját és az Oracle GraalVM környezetét vizsgálták. A legerősebb gyakorlati eredményt Linuxon érték el: két teljes támadási láncot dolgoztak ki, és bemutatták a rootfiók jelszó-hash-ének megszerzését. A BTR-kutatás eredeti közleménye
Az eredmények figyelmet érdemelnek, de a bizonyított kihasználhatóság határait is meg kell őrizni. A kutatás nem igazol egyformán teljes támadást minden vizsgált futtatókörnyezet és processzor esetében. Linuxon működő kihasználást mutattak be, a Firefoxnál további fejlesztést igénylő koncepcióigazolás készült, a GraalVM-kísérleteknél pedig gyakorlati akadályba ütköztek.
Hogyan válik biztonsági problémává egy régi elágazás-előrejelzés?
A modern processzorok a teljesítmény növelése érdekében előrejelzik a program következő lépéseit. Amikor a végrehajtás olyan közvetett elágazáshoz ér, amelynek célcíme csak futás közben derül ki, a processzor már azelőtt elkezdhet dolgozni egy feltételezett címen, hogy a helyes célcímet meghatározná.
A Linux kernel Spectre-dokumentációja ismerteti, hogyan befolyásolhatják a támadók ezeket az előrejelzéseket, majd hogyan következtethetnek érzékeny adatokra a processzor gyorsítótárában keletkező mellékhatásokból. A hibás spekuláció eredménye nem marad meg a program számára látható állapotban, de mérhető nyomokat hagyhat maga után. A Linux kernel Spectre-dokumentációja
A BTR ezt a problémát olyan végrehajtható memóriára alkalmazza, amelynek tartalma idővel megváltozik.
Egy JIT-motor létrehozhat egy függvényt, végrehajthatja, majd felszabadíthatja a hozzá tartozó memóriát. Később ugyanazt a memóriaterületet más utasítások tárolására használhatja fel. Az eredeti függvény ekkor már nincs jelen, de a korábbi belépési pontjára mutató elágazás-előrejelzés fennmaradhat.
Ha a processzor ismét ezt az előrejelzést használja, a spekulatív végrehajtás az új kódnak egy nem szándékolt pontján indulhat el.
A különbség a végrehajtható memória aktuális tartalmának helyes kezelése és az előrejelzési előzmények érvényessége között van. A processzor helyesen érzékelheti az új utasításokat, miközben továbbra is egy olyan célcímet jósol meg, amelyet akkor tanult meg, amikor az adott címeken más kód helyezkedett el.
Ez veszélyeztetheti azokat a szoftveres védelmeket, amelyek abból indulnak ki, hogy a végrehajtás a generált kód szabályos belépési pontján kezdődik, és így eléri az ott elhelyezett ellenőrzéseket.
Miért jelentenek vonzó célpontot a JIT-fordítók?
A JIT-fordítás széles körben elterjedt, mert ötvözi az értelmezett programnyelvek rugalmasságát a natív gépi kód sebességével. A gyakran használt függvények a program futása közben lefordíthatók, optimalizálhatók és lecserélhetők.
Ezek a teljesítményelőnyök azonban folyamatosan változó végrehajtható memóriát eredményeznek. Egy biztonsági vizsgálatnak ezért nemcsak azt kell ellenőriznie, hogy az újonnan létrehozott függvény szabályos végrehajtás mellett biztonságos-e. Azt is figyelembe kell vennie, hogy egy elavult előrejelzés elindíthatja-e a végrehajtást a függvény közepén.
Ez a fordító által beillesztett védelmi műveleteket is érinti. Egy memóriahatár-ellenőrzés vagy címmaszkolás korlátozhatja a memóriahozzáférést, ha az utasítások a tervezett sorrendben futnak le. Ha azonban a spekulatív végrehajtás az ellenőrzés után kezdődik, a védelem már nem feltétlenül szabályozza az azt követő hozzáférést.
A BTR ezért a processzor működése és a futtatókörnyezet memóriakezelése közötti kölcsönhatásról szól. Egy JIT-fordító jelenléte önmagában nem bizonyítja a működő kihasználást. A támadás lehetősége a kód elhelyezésétől, a memóriaterület újrafelhasználásától és az előrejelzési bejegyzések fennmaradásától is függ.
Mit bizonyított a Linuxon bemutatott támadás?
A Linux-demonstrációban a kutatók másodpercenként körülbelül 8 bájtos adatszivárgási sebességet értek el. Egy rootfelhasználóként történő hitelesítési kísérlet elindítása után kiolvasták az su folyamat memóriájában tárolt rootjelszó-hash-t.
Ez a sebesség alacsony egy szokásos fájlátvitelhez képest, de a célzott adatszerzéshez nem szükséges egy számítógép teljes memóriáját lemásolni. Kis méretű titkos adatok is jelentős értéket képviselhetnek, és a megfelelő információ megtalálása fontosabb lehet a nagy átviteli sebességnél.
A jelszó-hash megszerzésének jelentőségét ugyanakkor pontosan kell leírni. A hash kiolvasása nem fedi fel automatikusan az eredeti jelszót, és a bemutató önmagában nem igazol korlátlan rendszergazdai hozzáférést. Olyan adatot tesz hozzáférhetővé, amely offline jelszópróbálgatást támogathat. Ennek eredményessége a jelszótól és az alkalmazott hash-eljárástól függ.
A bemutatott kerneltámadáshoz az szükséges, hogy a támadó alacsony jogosultságú kódot futtathasson az érintett rendszeren. Nem önálló hálózati támadásról van szó, amely közvetlenül kompromittálhat bármely internetre kapcsolt Linux-szervert.
Ez a feltétel azonban nem teszi jelentéktelenné a kockázatot. A módszer releváns lehet megosztott számítási környezetekben és olyan rendszereken, amelyek nem megbízható forrásból származó feladatokat futtatnak. A helyi kódfuttatás továbbra is fontos biztonsági határ: egy egyszerű felhasználó vagy korlátozott folyamat nem olvashatná ki magasabb jogosultságú szoftverek titkos adatait.
Miért nem elegendő az eBPF korlátozása?
A kutatás egyik fontos megkülönböztetése a kiterjesztett BPF, vagyis az eBPF, valamint a régebbi, klasszikus BPF, azaz a cBPF közötti eltérés.
A kutatók szerint a cBPF az alacsony jogosultságú programok számára továbbra is elérhető lehet, például a seccomp-szűrésen keresztül. Egy szervezet ezért nem állapíthatja meg a bemutatott támadási felület hiányát pusztán abból, hogy a nem privilegizált eBPF használatát korlátozta.
A kernel BPF JIT-beállításainak dokumentációja egy külön védelmi lehetőséget is ismertet: a bpf_jit_harden beállítást, amely a JIT spraying típusú támadások ellen szolgál. A konfiguráció megkülönbözteti a kikapcsolt védelmet, a csak nem privilegizált felhasználókra alkalmazott védelmet és a minden felhasználóra érvényes védelmet. A Linux kernel BPF JIT-beállításainak dokumentációja
A BTR megmutatja, miért kell ezeket az intézkedéseket körültekintően értelmezni. Egy BPF-felülethez való hozzáférés korlátozása és a generált utasítások megerősítése a probléma összefüggő, de különböző részeit kezeli.
Egyik intézkedés megléte sem tekinthető önmagában annak bizonyítékának, hogy a generált kódhoz kapcsolódó valamennyi spekulatív támadási útvonal lezárult.
A rendszergazdáknak ezért azt kell ellenőrizniük, hogy a konkrét kernelcsomag tartalmazza-e a releváns javításokat, és hogy a rendszer a szállító által támogatott biztonsági konfigurációval működik-e.
A Firefox és a GraalVM esetében eltérőek a bizonyított eredmények
A böngészővel kapcsolatos megállapítások jelentősek, de kevésbé teljesek, mint a Linux-demonstráció.
A Firefox SpiderMonkey motorjánál a kutatók azt figyelték meg, hogy Intel processzorokon a régi előrejelzések túlélhetik a kódhoz tartozó memória felszabadítását és újrafoglalását. Koncepcióigazolásuk alapján másodpercenként néhány tíz bájtos adatszivárgás lehetősége merült fel. Ugyanakkor kifejezetten jelezték, hogy egy teljes böngészős támadáshoz további munka szükséges.
Ez szűkebb eredmény annál, mint ha igazolták volna a tetszőleges Firefox-lapokról történő adatlopást. A vizsgálat egy kezelendő mechanizmust mutat be, de nem bizonyítja a megbízható böngészős kihasználáshoz szükséges összes lépést.
A GraalVM eredményei szintén pontosítást igényelnek. A csapat azt vizsgálta, hogy a spekulatív végrehajtás átugorhatja-e azokat a címmaszkoló utasításokat, amelyek a vendégkód memóriahozzáférését korlátozzák.
Bár sikerült megfelelő cím-újrafelhasználást elérniük, a fordítási és szemétgyűjtési műveletek eltávolították az előrejelzési bejegyzéseket, mielőtt a teljes támadási sorozat felhasználhatta volna őket.
A kutatók szerint ez az akadály később leküzdhető lehet. Egy lehetséges továbbfejlesztési irány azonban nem azonos egy már bemutatott, működő támadással.
| Vizsgált környezet | A bemutatott eredmény | Fontos korlát |
|---|---|---|
| Linux cBPF | Két teljes támadási lánc, rootjelszó-hash kiolvasása | Helyi, nem privilegizált kódfuttatást igényel |
| Firefox SpiderMonkey | Koncepcióigazolás, fennmaradó előrejelzési bejegyzések | A teljes böngészős támadás további fejlesztést igényel |
| Oracle GraalVM | Megfelelő cím-újrafelhasználás elérése | A fordítás és a szemétgyűjtés megszüntette a szükséges előrejelzési állapotot |
Azoknak a szervezeteknek, amelyek bővítmények vagy ügyfelektől származó szkriptek futtatására használnak ilyen környezeteket, érdemes felülvizsgálniuk a frissítéseket és az elkülönítési határokat. A vizsgált platformokat nem indokolt azonos mértékben és azonos módon azonnal kihasználhatónak tekinteni.
A szoftveres javítások a kódmemória újrafelhasználását kezelik
A kutatók közleménye szerint a Linux fejlesztői olyan x86-os védelmet vezettek be, amely Indirect Branch Prediction Barrier, röviden IBPB műveletet hajt végre a processzormagokon, amikor egy cBPF-memóriafoglalás korábban végrehajtott BPF-kód által használt területet vesz ismét igénybe.
A módosítások az ilyen újrafelhasználás gyakoriságát is csökkentik, hogy ritkábban legyen szükség erre a műveletre.
A projekthez két Linux-sérülékenységi rekord kapcsolódik:
- CVE-2026-64507: IBPB-alapú törlés a BPF JIT-memóriafoglalás során;
- CVE-2026-64508: a JIT spraying elleni védelem megerősítése.
A kutatók ismertetése szerint az Oracle a GraalVM JIT-kódgyorsítótárának véletlenszerű elhelyezésével nehezíti meg a memóriaterületek kiszámítható újrafelhasználását. A Mozilla IBPB-alapú megoldásokat is mérlegelt, miközben a webhelyek elkülönítését, a site isolation megvalósítását részesítette előnyben.
Ezek a megoldások a kitettség eltérő részeit kezelik. Az előrejelzési korlátok az elavult processzorállapotot célozzák, a véletlenszerű elhelyezés a kód pozíciójának befolyásolását nehezíti, a folyamatok elkülönítése pedig korlátozza, hogy milyen titkos adatok kerülhetnek közös címtérbe nem megbízható kóddal.
A korábbi védelmek megkerülésére vonatkozó állítások a BTR-specifikus javítások előtti tesztkonfigurációkat írják le. Nem jelentik azt, hogy a most bevezetett javításokat is sikerült megkerülni.
Mit ellenőrizzenek a biztonsági csapatok?
Az első feladat annak megállapítása, hogy a közzétett problémákat kezelő operációsrendszer- és futtatókörnyezet-frissítések eljutottak-e az üzemelő rendszerekre.
Ehhez a Linux-disztribúciók biztonsági értesítései és csomagváltozási jegyzékei pontosabb támpontot adnak, mint az az általános kijelentés, hogy egy gép „teljesen frissített”. Ez különösen fontos akkor, ha a szállító a javításokat egy korábbi verziójú csomagba emeli vissza.
A Linux külön felületen jelzi a Spectre-védelmek állapotát. A Spectre v2 esetében ide tartozik a következő rendszerfájl:
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Ez hasznos információt ad az engedélyezett védelmekről, a konkrét BTR-javítások meglétét azonban külön kell ellenőrizni. A Spectre-védelmek állapotának Linux-dokumentációja
A kockázatalapú felmérésben kiemelt figyelmet indokolnak azok a gépek, ahol egymásban nem megbízó felhasználók vagy munkaterhelések osztoznak az erőforrásokon, valamint azok a szolgáltatások, amelyek szándékosan külső forrásból származó kódot futtatnak. Ez a támadás előfeltételeiből következik, nem abból, hogy minden ilyen telepítés bizonyítottan kihasználható lenne.
A BTR tágabb tanulsága, hogy a végrehajtható memória teljes életciklusának biztonsági jelentősége van. A kód lefoglalása, lecserélése és felszabadítása megváltoztathatja egy memóriacím szerepét anélkül, hogy a processzor korábban megtanult előrejelzései feltétlenül eltűnnének. A JIT-futtatókörnyezeteknek és az operációs rendszereknek ezt az előzményt is figyelembe kell venniük az elkülönítés fenntartásához.
Az eredeti angol cikk címe: New Spectre BTR Attack Exposes Linux Memory.
