Нови Spectre v2 напада JIT — root хеш је процурео за пет минута

5. октобар 2026. 02:00|Аутор: Уредништво QUASA|5 мин читања

Према извештају BleepingComputer-а, истраживачи VUSec-а при Универзитету у Амстердаму и италијанске Scuola Superiore Sant’Anna 29. септембра 2026. објавили су Branch Target Reuse (BTR), нови Spectre v2 напад на JIT компајлере; у Linux cBPF демонстрацији извукли су root хеш за просечно три минута на Intel Raptor Cove систему, односно пет минута на Lion Cove систему. Реч је о резултату контролисаног теста, а не о времену потребном за напад на сваки Linux рачунар.

На страници пројекта VUSec описана су два довршена напада на Linux језгро, засебна испитивања SpiderMonkey-а у Firefox-у и Oracle GraalVM-а, као и Linux исправке означене као CVE-2026-64507 и CVE-2026-64508. За прегледач и GraalVM приказани су ужи експериментални резултати, док је извлачење root хеша довршено у Linux cBPF окружењу. Та разлика је важна и за процену ризика и за избор исправке.

Зашто JIT код даје старом предвиђању нову мету

JIT компајлер током рада ствара машински код, ослобађа га када више није потребан и може поново да употреби исту извршну меморију. Процесор у међувремену памти куда су раније водили индиректни скокови како би унапред започео извршавање. Када на старој адреси стоји нови код, запис у предвиђачу скока може да преживи замену кода и да процесор накратко усмери на место које је имало смисла само у претходном распореду.

BTR користи тај несклад између JIT меморије и стања процесора. Нападач најпре изазива стварање кода на коме процесор учи мету скока, затим ослобађа ту област и настоји да JIT на истој адреси постави друга упутства. При следећем скоку процесор може спекулативно да уђе у нови код на застарелом померају, чак и између уобичајених граница упутстава. Тако настала упутства могу да приступе податку који исправан ток програма не би открио, а траг у кешу омогућава његово посредно очитавање.

Зато је распоред кода који JIT производи део напада, а не само место на коме се напад дешава. Старо предвиђање не враћа обрисани програм у меморију: оно усмерава краткотрајно извршавање у нови програм на погрешном месту. Разлика објашњава зашто замена машинског кода сама по себи не уклања запис који је процесор научио пре замене.

Шта је заиста процурело у Linux демонстрацији

У Linux огледу полазиште је био classic BPF, односно cBPF, чије филтере могу да постављају и непривилеговани процеси. JIT језгра претварао је те филтере у машински код. Демонстрација је најпре обучила предвиђач на једном cBPF програму, а затим је у поново употребљену меморијску област поставила други програм. Застарела мета скока усмерила је спекулативно извршавање у тај заменски код.

Напад није отворио датотеку са лозинком и прочитао је уобичајеним правима приступа. Покренут је процес „su“, који је root хеш учитао у меморију; експлоатација је затим пратила структуре процеса и меморијске странице док није дошла до тог податка. Хеш није лозинка у читљивом облику, али је осетљив јер се може употребити за покушаје њеног накнадног откривања. Приказан је и пут напада који заобилази cBPF заштиту за прикривање константи, па та опција није била довољна за испитану конфигурацију.

За разумевање резултата пресудни су услови огледа: приступ cBPF JIT-у, поновна употреба извршне области, одговарајући процес у меморији и мерљив спекулативни траг. Успех на испитаним Intel језгрима показује практичан пут до тајне мале величине. Само постојање истог понашања предвиђача на другом процесору или у другом JIT окружењу не даје аутоматски исти исход.

Погођено окружење и статус заштите

Linux cBPF: довршене демонстрације читају меморију језгра, укључујући root хеш из меморије процеса „su“. Исправка за x86 празни предвиђања индиректних скокова када се поново користи раније извршавана BPF JIT област и настоји да такву поновну употребу смањи. Администратор треба да провери безбедносно обавештење своје дистрибуције и да ли је ажурирано језгро заиста инсталирано.
Firefox SpiderMonkey: у прототипу су застарели записи предвиђача преживели ослобађање и поновно заузимање JIT меморије. WebAssembly код је показао могућност спекулативног уласка у извршни бафер, али није објављен довршен напад који извлачи податке из друге картице. Mozilla је разматрала заштиту засновану на чишћењу предвиђања, а предност је дала довршавању изолације сајтова; корисник треба да прати редовна издања Firefox-а.
Oracle GraalVM: испитивање са GraalPy-јем показало је да спекулативни скок може да прескочи проверу приступа меморији изолованог кода. Током огледа, међутим, компајлирање и сакупљање отпада брисали су потребне записе предвиђача пре довршетка напада. Oracle је увео насумичнији распоред JIT кодног кеша како би отежао поновну употребу исте области; они који покрећу непоуздане додатке или скрипте треба да провере верзију GraalVM-а коју испоручују.

Зашто датум објаве није датум Linux исправке

Phoronix-ов преглед Linux измена наводи да су BPF исправке ушле у главну грану језгра још у јулу 2026. и да су пренете у стабилне гране пре јавне објаве BTR-а. Зато систем који је био ажуриран у време ранијег лабораторијског теста није мерило стања сваког данас ажурираног језгра. Исто тако, постојање исправке у стабилној грани не значи да ју је свака дистрибуција већ испоручила или да је сваки рачунар покренут са том верзијом.

Linux заштита циља конкретан тренутак у ком поново употребљена JIT меморија може да се сретне са старим предвиђањем скока. GraalVM отежава да нови код уопште заузме погодну стару локацију, док Mozilla ради на изолацији која смањује доступност података између сајтова. То су различити одговори на исти механизам, усклађени са различитим степеном демонстрираног ризика. За Linux администратора одлучујући податак остаје статус исправке у језгру које машина стварно користи.

Прочитајте и: