DirtyFrag și CopyFail: vulnerabilități kernel Linux care escaladează la root. Ce să verifici?

În ultimele zece zile, comunitatea Linux a fost lovită de o cascadă neobișnuită de vulnerabilități kernel — toate din aceeași clasă page-cache write, toate ducând la privilege escalation locală de la utilizator neprivilegiat la root. CopyFail (CVE-2026-31431) a fost publicată pe 29 aprilie 2026 de echipa Xint sub titlul «Copy Fail: 732 Bytes to Root». Pe 7 mai 2026, cercetătorul sud-coreean Hyunwoo Kim (@v4bel) a publicat DirtyFrag — un exploit chained care înlănțuie CVE-2026-43284 (xfrm-ESP) și CVE-2026-43500 (RxRPC), după ce embargoul de divulgare responsabilă a fost spart de o terță parte.

Dacă administrezi un VPS sau un server dedicat, articolul acesta te privește direct — vulnerabilitățile sunt locale, dar pe un server cu mai mulți utilizatori SSH (developeri, freelanceri, conturi multiple, containere multi-tenant) un singur cont compromis înseamnă root pe toată mașina. Pe shared hosting tradițional cu cPanel, riscul direct este mai mic (utilizatorii nu au shell), dar furnizorul tău trebuie să reactioneze rapid: orice site PHP vecin care suferă un Remote Code Execution se transformă instant într-un usa deschisa către access root pe tot serverul.

Cele trei CVE-uri pe scurt

Toate trei aparțin aceleiași familii: scriere arbitrară în page cache. Adică atacatorul reușește să modifice copia în memorie a unui fișier de pe disc, ca și cum ar fi avut drepturi de scriere — chiar dacă fișierul este read-only, deținut de root, sau este un binar critic ca /usr/bin/su. Este aceeași clasă de bug ca Dirty Pipe (CVE-2022-0847), descoperit în 2022 de Max Kellermann, care a făcut atunci ocolul presei tehnice de specialitate.

CopyFail (CVE-2026-31431): 732 de bytes până la root

CopyFail exploatează un bug de logică introdus în 2017 în modulul algif_aead, parte din interfața AF_ALG a kernel-ului — care expune primitiva criptografică AEAD către userspace. Un program neprivilegiat poate trimite, prin syscall-uri obișnuite (socket(AF_ALG), setsockopt, sendmsg), date care ajung scrise direct în page cache, peste pagini deținute de fișiere read-only ale sistemului. Cercetătorii Xint au publicat un proof-of-concept de doar 732 de bytes în Python care suprascrie binarul /usr/bin/su și obține shell de root — un PoC remarcabil de minimalist comparativ cu DirtyPipe (peste 1.5 KB) sau DirtyCow (peste 30 KB).

Practic, orice distribuție Linux pornită din 2017 încoace este afectată. Companiile mari de gazduire web au publicat pe 5 mai 2026 ghidul oficial de securizare și au actualizat imaginile de bază pentru: AlmaLinux 8/9/10, Alpine 3.21/3.22/3.23, Arch, CentOS Stream 9, Debian 11/12/13, Fedora 42/43, Rocky 8/9, openSUSE Leap 15.6, Slackware 15, Ubuntu 20.04/22.04/24.04/25.10. 

DirtyFrag: două bug-uri lipite (xfrm-ESP + RxRPC)

DirtyFrag nu este o singură vulnerabilitate, ci un exploit chain care folosește una din două căi în funcție de privilegiile pe care atacatorul le are deja. Avantajul pentru atacatori: un singur binar de exploit funcționează pe toate distribuțiile mari, alegând automat ramura potrivită. Avantajul pentru cercetare: cele două bug-uri se acoperă reciproc — unde una nu merge, pornește cealaltă.

CVE-2026-43284 — xfrm-ESP Page-Cache Write

Subsistemul XFRM (folosit de IPsec) are o ramură de cod numită skip_cow care, în prezența unui frag dar fără frag_list, sare validarea și execută criptografia in-place peste pagini ale page cache-ului. Pașii de exploatare:

1. Atacatorul izolează context-ul cu unshare(CLONE_NEWUSER | CLONE_NEWNET) — disponibil prin user namespaces pe majoritatea distribuțiilor moderne.
2. Înregistrează 48 de Security Associations XFRM cu numere de secvență controlate, pentru a putea declanșa exact decriptarea dorită.
3. Folosește splice() pentru a planta pagini ale binarului /usr/bin/su în socket buffers de tip skb.
4. Trimite pachete ESP care declanșează crypto_authenc_esn_decrypt() peste paginile plantate — preprocesarea face un STORE de 4 bytes la poziția assoclen + cryptlen a destinației.
5. Repetă în chunk-uri de 4 bytes pentru a obține o primitivă arbitrary 4-byte STORE peste page cache.
6. Suprascrie primii 192 de bytes ai lui /usr/bin/su cu un mini-ELF care execută setgid(0); setuid(0); setgroups(0,NULL); execve("/bin/sh", NULL, ["TERM=xterm",NULL]).
7. Lansează /usr/bin/su — care, fiind setuid root, deschide un shell de root.

Costul: are nevoie de CAP_NET_ADMIN sau de capacitatea de a crea un namespace de rețea. Pe Ubuntu și Fedora cu user namespaces activate by default, este o cerință banală. Patch-ul a fost commitat în mainline cu hash f4c50a4034e6 și introduce detectarea flag-ului SKBFL_SHARED_FRAG în ramurile skip_cow, forțând fragmentele partajate prin skb_cow_data() pentru izolare corectă.

CVE-2026-43500 — RxRPC Page-Cache Write

Aceeași clasă de bug, dar într-un colț mai obscur al kernel-ului — protocolul RxRPC folosit de AFS (Andrew File System). De data asta atacatorul nu are nevoie de niciun privilegiu special. Pașii:

1. Brute-force în userspace: atacatorul caută o cheie simetrică fcrypt care, decriptată peste 8 bytes țintă, produce plaintext-ul dorit (este criptografic mai costisitor decât xfrm-ESP, dar fezabil în câteva minute pe CPU obișnuit).
2. Înregistrează cheia RxRPC găsită cu add_key().
3. Stabilește o conexiune RxRPC fictivă peste un socket UDP.
4. Folosește splice() pentru a planta pagini ale lui /etc/passwd în payload-ul socket-ului.
5. Trimite pachete care declanșează pcbc(fcrypt) decryption in-place peste primii 8 bytes ai payload-ului.
6. Linia 1 a lui /etc/passwd devine root::0:0:GGGGGG:/root:/bin/bash — câmpul de parolă este gol, iar su îl acceptă datorită PAM cu opțiunea nullok.
7. Atacatorul rulează su fără parolă și obține root.

Conform autorului: «xfrm-ESP Page-Cache Write oferă o primitivă STORE arbitrar de 4 bytes... RxRPC Page-Cache Write nu necesită privilegiul de a crea un namespace.» Bug-ul există în kernel din iunie 2023 (~2 ani de exploatabilitate latentă) și nu are încă patch upstream disponibil la momentul publicării — doar un identificator CVE rezervat pentru tracking.

Distribuții și kernel-uri testate cu succes de exploit

Lista nu este exhaustivă — autorul precizează în README că «un singur binar de exploit funcționează pe distribuțiile majore», ceea ce înseamnă că orice kernel comparabil din aceeași perioadă este afectat. Și mai important: exploatarea este deterministă, fără race conditions și cu rată mare de succes. Kernel-ul nu intră în panică în caz de eșec — deci nu există un semnal vizibil de tentativă pentru un administrator obișnuit.

Cum verifici dacă VPS-ul tău este vulnerabil

Dacă administrezi singur un VPS sau un server dedicat, există trei verificări rapide pe care le poți rula chiar acum.

1. Verifică versiunea kernel-ului

uname -r

Compară versiunea cu cea curentă stabilă a distribuției. Pe Debian și Ubuntu:

sudo apt update && apt list --upgradable 2>/dev/null | grep -i linux-image

Pe RHEL, AlmaLinux, Rocky, Fedora:

sudo dnf check-update kernel

Pe Ubuntu Pro și RHEL există livepatching (KernelCare, ksplice, livepatch), dar pentru bug-uri din această clasă reboot-ul este mai sigur — page cache-ul trebuie golit oricum, iar livepatch-urile nu evacuează paginile contaminate.

2. Verifică starea modulului algif_aead (CopyFail)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Trei rezultate posibile:

• =m — modul kernel încărcabil. Vulnerabil. Mitigare: blacklist + rmmod (vezi mai jos).
• =y — compilat direct în kernel. Vulnerabil. Mitigare: parametrul GRUB initcall_blacklist=algif_aead_init + reboot.
• # ... is not set — sigur. Nu ai nevoie de mitigare pentru CopyFail (deși DirtyFrag rămâne).

3. Verifică modulele esp4, esp6, rxrpc (DirtyFrag)

lsmod | grep -E '^(esp4|esp6|rxrpc)\b'

Dacă vezi vreun rezultat — DirtyFrag te poate atinge. Pe un server obișnuit care nu folosește IPsec sau AFS, modulele sunt încărcate adesea pentru că un binar oarecare le-a triggerit auto-load. Pot fi blacklist-ate fără regrete dacă serverul nu e capăt de tunel VPN IPsec sau client AFS.

Mitigare temporară până la patch oficial

Pentru CopyFail (CVE-2026-31431), dacă algif_aead este modul încărcabil:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null

Pentru DirtyFrag (CVE-2026-43284 + 43500), aplică mitigarea oficială recomandată chiar de cercetătorul care a publicat exploit-ul:

sudo sh -c 'cat > /etc/modprobe.d/dirtyfrag.conf << EOF
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF'

sudo rmmod esp4 esp6 rxrpc 2>/dev/null
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Atenție: dacă serverul folosește activ IPsec (de exemplu, conexiuni VPN site-to-site sau tuneluri Strongswan), esp4 și esp6 sunt obligatorii și nu pot fi dezactivate. În acest caz, singura opțiune este aplicarea patch-ului upstream când va fi disponibil pe distribuția ta. Pasul echo 3 > /proc/sys/vm/drop_caches este critic — el golește page cache-ul de eventualele pagini contaminate de un atacator înainte ca patch-ul să fie aplicat. Reboot-ul are același efect.

Containere Docker și Kubernetes

Docker implicit blochează socket-urile AF_ALG prin profilul seccomp default — deci CopyFail nu poate fi exploatată dintr-un container Docker pornit fără --security-opt seccomp=unconfined. Dar pentru DirtyFrag situația e diferită: namespace-urile de utilizator sunt ușor disponibile în multe configurații moderne (mai ales în K8s cu user namespaces activate), iar varianta RxRPC nu necesită deloc namespace. Verifică profilul seccomp al containerelor tale și dezactivează modulele esp4/esp6/rxrpc la nivel de host:

# Verifică profilul seccomp al unui container Docker
docker inspect --format '{{json .HostConfig.SecurityOpt}}' nume_container

# Pentru K8s, verifică Pod Security Standards
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.securityContext}{"\n"}{end}'

Pe Kubernetes (inclusiv managed precum Linode LKE, AWS EKS, Google GKE, Azure AKS), recomandarea oficială este reciclarea node pool-urilor pe imagini cu kernel patched. RuntimeDefault seccomp nu este suficient — DirtyFrag nu necesită capabilități speciale care să fie blocate de seccomp default. Dacă rulezi workload-uri untrusted (multi-tenant SaaS, build runners, sandbox de cod, CI runners pentru proiecte open source), prioritate maximă pentru patch.

Pe shared hosting (cPanel, Plesk) ești afectat?

Răspunsul scurt: nu direct, dar indirect da. Pe shared hosting tradițional, conturile de utilizator nu au acces SSH cu shell — doar SFTP chroot-uit, comenzi cPanel restricționate, fără posibilitatea de a executa binari arbitrari. Asta înseamnă că tu, ca proprietar de site, nu poți declanșa niciun exploit local și nu te poți compromite singur.

Dar dacă un alt site de pe același server are o vulnerabilitate de tip RCE — un plugin WordPress vulnerabil, un theme care permite eval(), un upload nesanitizat, o componentă Joomla din 2018 — atacatorul care obține execuție de cod ca utilizator obișnuit poate folosi DirtyFrag sau CopyFail pentru a escala la root. Și de acolo controlează toate site-urile de pe server, inclusiv pe al tău. Logurile de acces nu vor arăta nimic suspect dinspre site-ul tău — atacul a venit prin altcineva.

În alte cuvinte: pe shared hosting, securitatea ta depinde de cea mai slabă verigă de pe server. Vecinul cu un plugin neactualizat din 2019 te poate compromite indirect, prin chained exploitation. De aceea, viteza cu care furnizorul de hosting aplică patch-urile pentru bug-uri kernel ca acestea este un indicator critic al calității serviciului.

Ce să întrebi furnizorul tău de hosting

Indiferent că ești pe shared, VPS managed sau dedicat managed — dacă nu administrezi tu kernel-ul, trebuie să întrebi furnizorul. Trimite-i acest articol și cere răspunsuri concrete (poți copia direct lista în email):

1. Ați actualizat kernel-ul pe serverul pe care este găzduit site-ul meu pentru CopyFail (CVE-2026-31431)? Care este versiunea curentă instalată?
2. Aveți planuri pentru DirtyFrag (CVE-2026-43284 + CVE-2026-43500)? Ați aplicat mitigarea temporară (blacklist esp4/esp6/rxrpc) până la disponibilitatea patch-ului oficial?
3. Folosiți livepatching (Ubuntu Pro KernelCare, Oracle Ksplice, Red Hat Livepatch) sau patch-urile de kernel necesită reboot programat? Care este SLA-ul vostru pentru ferestrele de mentenanță de securitate?
4. În fereastra de risc dintre dezvăluirea publică (29 aprilie 2026 pentru CopyFail, 7 mai 2026 pentru DirtyFrag) și aplicarea patch-ului, monitorizați activ indicatori de compromitere — modificări la /usr/bin/su, /etc/passwd, /etc/shadow, hash-uri ale binarelor setuid?
5. Profilul seccomp al containerelor pe care le rulați include blocarea AF_ALG?
6. În cazul unui incident detectat, aveți un proces clar de notificare a clienților afectați și de restaurare din backup curat?

Furnizorii serioși au deja un advisory intern și o fereastră de mentenanță programată. Dacă răspunsul este vag, evaziv sau «vom verifica», este un semnal că furnizorul nu are un proces de patch management matur. Pentru workload-uri de business care depind de uptime și securitate, e rezonabil să iei în considerare migrarea — putem să îți recomandăm un furnizor cu disciplină solidă în această zonă.

Familia "page-cache write" — un patern în creștere

DirtyFrag și CopyFail sunt verii direcți ai unei vulnerabilități celebre din 2022 — Dirty Pipe (CVE-2022-0847), descoperită de Max Kellermann. În toate cele patru cazuri, defectul este același: o cale ne-evidentă în kernel prin care userspace-ul ajunge să scrie date în pagini de memorie pe care n-ar fi trebuit să le poată atinge.

• Dirty Pipe (2022) — folosește splice() direct în pipe, exploatează un bug în copy_page_to_iter_pipe().
• CopyFail (2026) — folosește interfața AF_ALG și modulul algif_aead.
• DirtyFrag/ESP (2026) — folosește XFRM/IPsec și ramura skip_cow.
• DirtyFrag/RxRPC (2026) — folosește protocolul AFS RxRPC și decriptarea PCBC in-place.

Asta sugerează un patern: kernel-ul Linux are sute de căi către page cache prin diverse subsisteme și protocoale obscure, fiecare o potențială sursă de astfel de bug-uri. Cercetătorii de securitate vor continua să găsească vulnerabilități din această familie, iar disciplina de patch management va deveni din ce în ce mai importantă pentru orice operator de servere — de la datacenter-uri mari la VPS-uri de 5 EUR pe lună.

Pentru proprietarii de site-uri, lecția este simplă: alege furnizori care patchează rapid. Întreabă-i. Verifică-i. Iar dacă nu îți răspund, schimbă-i. La HostPedia urmărim continuu cum reacționează furnizorii din România la vulnerabilitățile critice — și actualizăm clasamentele în consecință.

Resurse pentru aprofundare

• github.com/V4bel/dirtyfrag — repo-ul oficial publicat de Hyunwoo Kim cu PoC, write-up tehnic detaliat și kernel-uri testate.
• linode.com — CVE-2026-31431 Copy Fail Mitigation — ghidul oficial Linode cu pași detaliați pentru toate distribuțiile populare.
• nvd.nist.gov — Dirty Pipe (CVE-2022-0847) — vulnerabilitatea originală din 2022, pentru context istoric.
• Codul sursă afectat: net/ipv4/esp4.c, net/ipv6/esp6.c, net/rxrpc/call_event.c, net/rxrpc/conn_event.c, crypto/algif_aead.c în arborele kernel Linux.

Dacă citești acest articol și administrezi un server — verifică acum. Dacă administrezi un site pe shared hosting — trimite articolul furnizorului tău.