Shadow stack compromis: trei ocoliri Linux la DEF CON 34
Sâmbătă, 8 august 2026, la DEF CON 34, cercetătorul Vladimir Tokarev a prezentat trei tehnici prin care un proces poate scrie valori alese de atacator direct în memoria shadow stack pe Linux. Demonstrațiile au inclus Intel CET pe x86-64, ARM64 GCS și un root shell obținut cu CET încă activ.
Nu este un zero-day care oferă singur acces de la distanță. Atacatorul are nevoie de o vulnerabilitate de corupere a memoriei și de precondițiile fiecărei tehnici. Descoperirea arată însă că o mitigare hardware nu poate compensa toate căile de scriere oferite de sistemul de operare.
Ce protejează shadow stack
Intel Control-flow Enforcement Technology păstrează adresele de retur într-o stivă separată, protejată. La revenirea dintr-o funcție, procesorul compară adresa din stiva normală cu cea din shadow stack; o nepotrivire oprește fluxul deturnat.
Pe Linux, suportul pentru user shadow stack trebuie să existe în procesor, kernel și binarul executat. Documentația kernelului arată cum poate fi verificată capabilitatea CPU, nota ELF și starea procesului. Prezența CET în fișa procesorului nu dovedește că fiecare serviciu îl folosește.
Cele trei căi de scriere
Toate cele trei ajung la același rezultat — valori alese de atacator în zona pe care mecanismul de control-flow o consideră de încredere — dar folosesc suprafețe diferite ale kernelului și procesorului. De aceea, schimbarea pentru /proc/self/mem nu închide automat userfaultfd sau WRSSQ.
- ▸/proc/self/mem: mecanismul FOLL_FORCE putea forța scrierea într-o regiune care altfel nu este inscriptibilă; tehnica a funcționat pe x86-64 CET și ARM64 GCS
- ▸userfaultfd: o pagină din VMA-ul shadow stack este eliminată cu MADV_DONTNEED, apoi fault-ul este rezolvat cu o pagină de înlocuire controlată
- ▸WRSSQ: instrucțiunea destinată explicit scrierii în shadow stack poate fi emisă din user mode atunci când funcția este activată
Ce schimbă patch-ul Linux — și ce nu
După raportare, commitul 599bbba5a36f a schimbat alegerea implicită pentru noile configurații spre PROC_MEM_FORCE_PTRACE. Astfel, FOLL_FORCE prin /proc/pid/mem este rezervat operațiilor ptrace, în loc să fie permis mai larg.
Nu este o remediere universală și nici o schimbare retroactivă a tuturor sistemelor. Mesajul commitului precizează că o configurație existentă păstrată prin make oldconfig rămâne la opțiunea veche. Administratorii trebuie să inspecteze configurația kernelului livrată de distribuție, nu să deducă starea din numărul versiunii.
În plus, rezumatul cercetării spune explicit că traseul userfaultfd nu este blocat de prima schimbare. Patch-ul reduce o suprafață; nu face irelevante vulnerabilitatea de bază sau celelalte primitive.
Impact real, cu precondiții reale
Cercetătorul a validat tehnicile împotriva a trei vulnerabilități din dnsmasq, libinput și rsync și a demonstrat exploatarea pe hardware real, inclusiv un root shell cu CET activ. Rezumatul public nu enumeră însă ID-urile CVE, versiunile aplicațiilor sau configurația completă pentru fiecare demo.
Prin urmare, nu trebuie tradus în „orice utilizator poate deveni root”. Este o metodă de a transforma anumite primitive existente într-un lanț care trece de shadow stack. Privilegiile inițiale, bug-ul de memorie, funcțiile activate și granița procesului determină rezultatul.
Ce verifică o echipă Linux acum
- ▸aplică actualizările de kernel livrate de distribuție și urmărește advisories, nu doar versiunea upstream
- ▸inspectează configurația efectivă pentru opțiunile CONFIG_PROC_MEM_FORCE_*; nu presupune că noul default a modificat un kernel deja configurat
- ▸verifică separat suportul CPU, proprietățile ELF și starea shadow stack a proceselor critice conform documentației kernelului
- ▸menține vm.unprivileged_userfaultfd la 0 dacă aplicațiile nu cer altceva și controlează permisiunile pentru /dev/userfaultfd
- ▸prioritizează patch-urile pentru bug-urile de corupere a memoriei din serviciile expuse; CET este defense-in-depth, nu înlocuitor
- ▸monitorizează accesul neobișnuit la /proc/*/mem și folosirea userfaultfd sau MADV_DONTNEED în servicii sensibile, cu o bază de comportament legitim
Semnalul corect pentru risc
Nu există în rezumat dovadă de exploatare în sălbăticie și nici ID-uri CVE pentru cele trei demonstrații. Până la publicarea lor, alerta utilă este despre configurația kernelului și vulnerabilitățile de memorie din software-ul instalat, nu despre un CVE imaginar numit „shadow stack bypass”.
MONITOR AWARELY poate corela CVE-urile publice pentru dnsmasq, libinput, rsync sau kernel cu versiunile din inventar. Echipa de platformă trebuie să adauge contextul pe care feedurile nu îl conțin: dacă CET este activ, dacă userfaultfd este necesar și ce model de amenințare are serviciul.
Urmărește vulnerabilitatea de bază, nu doar mitigarea
MONITOR AWARELY corelează CVE-urile publice cu versiunile tale. Shadow stack rămâne defense-in-depth: patch-urile pentru aplicație și kernel sunt în continuare controlul principal.