OpenAI: 948 de căi spre root în Linux. Ce schimbi pe serverul firmei

Pe un server Linux există două feluri de conturi. Contul root poate face orice. Celelalte, cum este www-data, sub care rulează site-ul, sau contul programatorului extern, pot face foarte puțin. Pe această separare se sprijină o bună parte din securitatea unui server.

Pe 4 noiembrie 2026, OpenAI a publicat cercetarea „A thousand fewer paths to root”. Un sistem automat, construit în jurul unui model AI, a căutat în kernelul Linux vulnerabilități prin care un cont obișnuit devine root. A găsit și a exploatat 948, într-o singură rulare.

Concluzia autorilor este cea care te privește. Un cont fără privilegii pe un sistem de operare care nu are ultimele patch-uri trebuie considerat echivalent cu acces de root, pentru un atacator cu resurse. Dacă firma ta are un server Linux, la sediu sau închiriat, regula după care îl actualizezi trebuie revăzută.

Ce a făcut OpenAI, în cifre

Kernelul este nucleul sistemului de operare, partea care controlează memoria, discurile și rețeaua. O vulnerabilitate de escaladare locală a privilegiilor (LPE) este o eroare din kernel prin care un program pornit de un utilizator obișnuit ajunge să ruleze ca root.

Sistemul descris de OpenAI are cinci etape: agenți care aleg ce cod merită verificat, agenți care caută erori, reproducerea fiecărei erori într-o mașină virtuală izolată, scrierea unui exploit funcțional și generarea unui patch. La final, cercetători umani verifică totul înainte de raportare.

Cifrele sunt din articolul OpenAI și se regăsesc în relatarea Help Net Security. Diferența dintre 1.169 și 948 vine din faptul că mai multe exploit-uri lovesc aceeași eroare.

Ținta nu a fost un sistem slăbit pentru test. Mașinile virtuale rulau un sistem desktop obișnuit, cu protecțiile standard ale distribuției active, pe cea mai nouă versiune de kernel de la acea dată. OpenAI nu numește distribuția.

Pentru comparație, competițiile de securitate Pwn2Own și TyphoonPWN au plătit 20.000, respectiv 70.000 de dolari pentru un singur exploit de acest tip. Aici, unul a costat cât un laptop de serviciu.

De la 166 la 948 în trei luni

OpenAI a rulat același sistem de două ori. La sfârșitul lui iulie 2026, cu modelul GPT-5.6 Sol, a găsit și exploatat 166 de vulnerabilități, cu 513.690 de dolari. La mijlocul lui octombrie, cu un model mai nou, a găsit 948.

Între cele două rulări, kernelul a primit trei luni de corecții. Un model mai bun a găsit de peste cinci ori mai multe probleme în cod care fusese deja verificat și reparat. Autorii spun că proiectele mari vor avea nevoie de mai multe runde de scanare și reparare, câte una la fiecare generație de modele.

Modelul din octombrie nu este numit în articol. A doua zi, OpenAI a anunțat GPT-6 Cyber, disponibil deocamdată unui număr limitat de clienți din programul Daybreak Red. CyberScoop prezintă cele 948 de exploit-uri ca demonstrație a capacităților noii generații.

Mai sunt două observații utile. Într-un eșantion de 166 de exploit-uri, cercetătorii au identificat 10 tehnici de exploatare pe care nu le mai văzuseră; detaliile nu au fost publicate. Iar într-o rulare timpurie, 20 din 200 de exploit-uri ajunseseră la root printr-o altă vulnerabilitate, necunoscută, decât cea primită ca temă.

De ce te privește, dacă nu ești ținta unui stat

„Cont fără privilegii” sună a ceva ce atacatorul nu are. În practică, îl obține ușor, pe una dintre aceste căi:

• O vulnerabilitate în site. Erorile din PHP despre care am scris în articolul despre patch-urile din octombrie îi dau atacatorului exact contul www-data.
• Un cont SSH al unui programator, al unui colaborator extern sau al unui fost angajat, cu parola refolosită sau furată.
• Găzduirea partajată, unde alți clienți ai furnizorului au conturi pe același kernel ca site-ul tău.
• Un container Docker. Containerele de pe un server folosesc același kernel ca serverul.

Până acum, o astfel de intrare însemna de obicei un site stricat. Cu un exploit de kernel, înseamnă tot serverul: bazele de date, backupurile montate, cheile și parolele celorlalte aplicații.

OpenAI mai face o predicție. În câțiva ani, modelele de vârf vor găsi probabil orice vulnerabilitate existentă într-un proiect, iar modele mai slabe vor putea scrie exploit-uri pornind de la patch-ul publicat. Asta înseamnă că fiecare actualizare de kernel pe care nu ai instalat-o este, pentru atacator, o instrucțiune.

Ce nu spune cercetarea

Cifrele sunt mari și merită citite cu măsură.

• Nu sunt atacuri de la distanță. Toate cele 948 cer ca atacatorul să poată rula deja cod pe mașină.
• Nimeni din afara OpenAI nu a reprodus rezultatele, iar modelul nu este disponibil public.
• Cercetarea privește doar Linux. OpenAI spune că aceeași abordare se aplică și software-ului proprietar, dar nu publică cifre pentru Windows.
• OpenAI nu spune dacă exploit-urile funcționează din interiorul unui container. Recomandă însă izolare suplimentară, cu Firecracker sau gVisor, deci nu tratează containerul ca pe o barieră suficientă.
• Nu toate cele 948 sunt reparate. După zece zile, 61 erau corectate în kernelul oficial, 43 aveau patch-uri în pregătire și 299 erau în discuție publică. Restul se trimit treptat, împreună cu partenerii din inițiativa Patch the Planet.

Ultimul punct are o consecință directă. Nici un server actualizat la zi nu este acoperit complet, pentru că o parte din corecții încă nu există. Actualizarea este necesară, dar trebuie dublată de separare.

Cum verifici serverul tău

Pașii de mai jos sunt pentru Ubuntu și Debian, cele mai răspândite la firmele mici.

1. Vezi ce kernel rulează acum și dacă serverul așteaptă o repornire:

uname -r
ls /var/run/reboot-required
uptime

Dacă fișierul reboot-required există, o actualizare instalată nu este încă activă. Un uptime de câteva luni spune același lucru.

2. Instalează actualizările și repornește:

sudo apt update && sudo apt upgrade
sudo reboot

După repornire, uname -r trebuie să arate o versiune mai nouă.

3. Verifică actualizările automate. Pe Ubuntu Server, pachetul unattended-upgrades este instalat implicit și aplică zilnic actualizările de securitate, conform documentației Ubuntu. Repornirea automată este însă dezactivată implicit: opțiunea Unattended-Upgrade::Automatic-Reboot din /etc/apt/apt.conf.d/50unattended-upgrades are valoarea false. Kernelul nou se instalează, dar serverul rulează în continuare pe cel vechi.

4. Pe Debian, nu presupune nimic. Wiki-ul Debian spune că pachetul poate lipsi sau poate fi dezactivat. Verifici cu sudo dpkg-reconfigure unattended-upgrades.

Ce poți face de mâine

1. Stabilește o repornire săptămânală a fiecărui server Linux, într-o fereastră agreată, de exemplu duminică la 6:00. Fără repornire, patch-ul de kernel nu se aplică.
2. Fă lista conturilor de pe fiecare server: getent passwd | grep -v nologin. Șterge-le pe cele ale foștilor colaboratori și treci accesul SSH pe chei, fără parole.
3. Mută site-ul public de pe serverul cu datele firmei. Un site expus pe internet și baza de date a contabilității nu au ce căuta pe același kernel. O mașină virtuală separată este suficientă.
4. Întreabă furnizorul de găzduire, în scris, ce versiune de kernel rulează și cât de des repornește serverele. Pe găzduire partajată, răspunsul lui este singura ta protecție.
5. Nu amâna firmware-ul. Routerele, NAS-urile și telefoanele Android folosesc tot kernelul Linux, iar corecțiile ajung la ele doar prin actualizările producătorului.

Unde nu se potrivește

Repornirea săptămânală presupune că firma acceptă câteva minute de oprire. Unde nu se poate, soluția corectă este un al doilea server care preia sarcina, nu amânarea actualizării.

Există și varianta fără repornire. Canonical Livepatch aplică patch-uri de kernel din mers, dar acoperă doar vulnerabilitățile cu severitate ridicată și critică. Este gratuit pentru uz personal sau evaluare, pe cel mult 5 mașini; o firmă are nevoie de abonament Ubuntu Pro.

Pe echipamentele ieșite din suport nu există patch-uri de kernel. Un NAS sau un router care nu mai primește firmware se scoate de pe internet sau se înlocuiește. Iar Firecracker și gVisor, recomandate de OpenAI, sunt unelte pentru cine găzduiește codul altora; pentru o firmă mică, echivalentul practic este mașina virtuală separată.

Cum procedăm noi

La clienții cu management IT externalizat, serverele Ubuntu și Debian sunt urmărite prin Brio Endpoint Manager, prin SSH, fără nimic instalat pe server. Platforma numără separat actualizările de securitate disponibile și ridică alertă când acestea rămân neaplicate sau când serverul așteaptă o repornire. Aplicarea actualizărilor și repornirea se fac din interfață, în fereastra de mentenanță agreată cu clientul.

Nu avem o metodă prin care să detectăm un exploit de kernel necunoscut, și nu promitem asta. Ce putem face este să scurtăm intervalul dintre apariția patch-ului și repornire și să ținem pe fiecare server cât mai puține conturi și aplicații.

Dacă ai un server Linux și nu știi când a fost repornit ultima dată, rulează uname -r și uptime și trimite-ne rezultatul. Îți spunem în aceeași zi cât de vechi este kernelul și ce ar trebui făcut prima dată.