Acces Clienti

Acces Clienti

Copy Fail (CVE-2026-31431): cum o singură linie de comandă greșită vă poate lăsa serverele vulnerabile

3 mai 2026 | Securitate

Pe 30 aprilie 2026, cercetătorii de la Theori (echipa Xint Code) au publicat detaliile despre CVE-2026-31431, denumită informal „Copy Fail”. Este o eroare de logică în kernel-ul Linux care permite oricărui utilizator local neprivilegiat să obțină drepturi de root prin executarea unui simplu script Python de 732 de octeți. Toate distribuțiile Linux majore lansate începând cu 2017 sunt afectate — RHEL, AlmaLinux, Rocky, CloudLinux, Ubuntu, Debian, SUSE, Amazon Linux. Practic: dacă rulați Linux în producție, sunteți afectat.

Vulnerabilitatea are scor CVSS 7.8 și este deja exploatabilă în mod fiabil. PoC-ul este public.

În acest articol explic ce este vulnerabilitatea, de ce contează în mod special pentru cei care operează infrastructură de hosting cu hipervizoare KVM, și — mai important — de ce mitigarea recomandată inițial pe oss-security nu funcționează pe distribuțiile RHEL-family, lăsând administratorii cu o falsă senzație de protecție.

Ce este, mai exact, „Copy Fail”

Vulnerabilitatea se află în modulul algif_aead, parte din interfața AF_ALG a API-ului criptografic al kernel-ului. AF_ALG este o interfață prin socket-uri care permite proceselor din userspace să folosească algoritmii criptografici implementați în kernel — util în special pentru sisteme cu accelerare hardware (AES-NI, motoare criptografice dedicate pe SoC).

Pe scurt, problema apare astfel:

  1. În 2011, a fost adăugat în kernel template-ul criptografic authencesn (folosit pentru IPsec).
  2. În 2015, AF_ALG a primit suport pentru AEAD (Authenticated Encryption with Associated Data), cu un path prin splice() care putea aduce pagini din page cache direct în scatterlist-ul criptografic.
  3. În 2017, a fost adăugată o „optimizare” în algif_aead.c pentru ca operațiile AEAD să se execute in-place (sursa și destinația în același scatterlist).

Combinând cele trei modificări — toate rezonabile individual — apare o situație în care un atacator poate scrie 4 octeți controlați într-o pagină din page cache a oricărui fișier citibil de pe sistem, inclusiv binare setuid. Modifica unui binar setuid inseamna acces root.

Detaliile tehnice complete sunt în articolul original al Theori. Este un studiu de caz interesant despre cum interacțiuni inocente între patch-uri de-a lungul anilor pot crea vulnerabilități critice.

De ce contează (chiar dacă „nu am utilizatori shell”)

Prima reacție pe care o aud de la colegi este: „OK, dar pe nodurile mele KVM mele nu intră nimeni în afară de root prin SSH. De ce m-ar deranja un LPE?”

Răspunsul scurt: pentru că într-o arhitectură de hosting niciodată nu aveți doar root. O verificare rapidă pe orice hipervizor SolusVM 2 / RHEL 9 + KVM va arăta cel puțin următoarele UID-uri non-root active:

  • qemu / libvirt-qemu — fiecare proces QEMU al fiecărui guest rulează sub acest UID
  • nginx / apache dacă agentul SolusVM sau alte componente web rulează local
  • Conturi de serviciu pentru agenți de monitorizare (Netdata, Zabbix, node_exporter)
  • polkitd, dbus, chrony, systemd-* — suprafața mică, dar tot non-root

Aici devine interesant pentru un operator de hosting: boundary-ul de securitate al QEMU. În mod normal, un atacator care reușește un escape din QEMU (printr-un alt CVE — și apar regulat) ajunge pe gazdă cu drepturi de utilizator qemu. Asta este o conținere importantă: nu poate citi disk image-urile altor clienți, nu poate atinge baza de date SolusVM, nu poate manipula /etc/libvirt/.

CVE-2026-31431 distruge acest al doilea strat de apărare. Un escape QEMU care ar fi fost „neplăcut, dar conținut” devine „root instant pe hipervizor, toate VM-urile clienților compromise, credențiale SolusVM expuse”.

Chiar dacă probabilitatea unui escape QEMU este mică, modelul „defense in depth” presupune că atunci când boundary-ul intern cedează, cel extern încă rezistă. CVE-ul de față îl elimină pe acesta din urmă.

Mitigarea care nu funcționează pe RHEL

Aici ajungem la partea care m-a făcut să scriu acest articol. Ghidul de mitigare publicat inițial pe oss-security și replicat în zeci de locuri sună așa:

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

Pe RHEL, AlmaLinux, Rocky, CloudLinux — această mitigare nu face absolut nimic.

Motivul este simplu: pe distribuțiile RHEL-family, algif_aead nu este compilat ca modul kernel separat (.ko), ci este integrat direct în kernel (CONFIG_CRYPTO_USER_API_AEAD=y). Regulile din /etc/modprobe.d/ se aplică doar modulelor încărcabile. Iar rmmod nu poate descărca cod care face parte din imaginea kernel-ului.

Verificați chiar acum pe orice hipervizor RHEL:

modinfo algif_aead | grep filename
# Output: filename: (builtin)

Dacă apare (builtin), comenzile de mai sus au rulat fără erori, dar nu au schimbat nimic. Sistemul rămâne vulnerabil. Iar admin-ul crede că a aplicat mitigarea.

Aceasta este o problemă serioasă pentru că este probabil ca multe ghiduri interne, runbook-uri și răspunsuri de la copy-paste-AI-tools să propage această mitigare neaplicabilă.

Mitigarea care funcționează pe RHEL

Soluția corectă pe RHEL/AlmaLinux/Rocky/CloudLinux este să blocați inițializarea funcției algif_aead_init la boot, prin parametrul initcall_blacklist:

sudo grubby –update-kernel=ALL –args=„initcall_blacklist=algif_aead_init”
sudo reboot

 

Verificare după reboot:

grep initcall_blacklist /proc/cmdline
# Trebuie să apară: initcall_blacklist=algif_aead_init

Această abordare instruiește kernel-ul să sară peste înregistrarea interfeței AEAD AF_ALG la pornire. Codul vulnerabil rămâne în imaginea kernel-ului, dar nu este accesibil din userspace. Necesită reboot — nu există echivalent runtime, exact pentru că funcționalitatea este built-in.

După instalarea unui kernel actualizat (urmăriți RHSA-ul Red Hat sau echivalentul AlmaLinux), inversati modificarea:

sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
sudo reboot

Impact funcțional: aproape zero pe un hipervizor de hosting

Înainte de a aplica mitigarea, întrebarea evidentă este: „Ce se va strica?”

Pe un stack tipic de hosting (RHEL 9 + KVM + SolusVM 2 + LiteSpeed/Apache/Nginx + MariaDB/MySQL), răspunsul este: nimic. Componentele care folosesc criptografie pe hipervizor trec prin biblioteci userspace (OpenSSL, GnuTLS, libgcrypt), fara AF_ALG:

  • TLS pentru web servers — OpenSSL/LibreSSL userspace
  • SSH — OpenSSL userspace
  • MySQL/MariaDB connections — userspace
  • KVM/QEMU pentru VNC/SPICE/migration — gnutls/nettle userspace
  • libvirt — libgcrypt userspace
  • LUKS/dm-crypt — folosește direct API-ul criptografic kernel, nu prin socket-uri AF_ALG
  • WireGuard, IPsec via XFRM — paths separate în kernel, nu trec prin algif_aead
  • kTLS — ULP separat în kernel

Singurele candidate plauzibile pe un hipervizor RHEL care ar putea folosi AF_ALG:

  • systemd cu LoadCredentialEncrypted= în unit files (rar pe hosting standard)
  • OpenSSL cu engine-ul afalg activat manual (default este off)
  • Aplicații custom care folosesc libkcapi

Verificați rapid:

sudo lsof 2>/dev/null | grep AF_ALG
openssl engine -t -c 2>/dev/null | grep -i afalg
systemctl show '*' --property=LoadCredentialEncrypted 2>/dev/null | grep -v '=$'
rpm -qa | grep -iE 'libkcapi|kcapi'

Dacă toate cele patru returnează gol — și pe un hipervizor stock vor returna gol — mitigarea este sigură.

Hipervizor vs guest: două lumi separate

Un punct care merită clarificat explicit, pentru că generează multă confuzie: mitigarea aplicată pe hipervizor nu protejează în niciun fel guest-urile și nici nu le afectează funcțional.

LayerMitigarea pe host?Necesită fix propriu?
Kernel hipervizor✅ DaKernel actualizat când va fi disponibil
Kernel guest VM❌ NuFiecare guest se patch-uiește independent
Lanț QEMU-escape → host root✅ Da (avantajul real)—

Fiecare VM rulează propriul kernel, complet separat. Când un proces din interiorul unui guest face socket(AF_ALG, ...), syscall-ul este servit de kernel-ul guest-ului — nu ajunge niciodată pe host. Asta înseamnă două lucruri:

  1. Aplicând initcall_blacklist=algif_aead_init pe hipervizor, niciun client nu va observa nicio diferență în VM-ul lui. Aplicațiile, baza de date, certificatele SSL, totul funcționează identic.
  2. Clienții care au shell users, CI runners sau aplicații web vulnerabile la RCE în VM-urile lor sunt în continuare expuși la CVE-2026-31431 — în interiorul propriilor VM-uri. Trebuie patchu-iți separat.

Pentru servicii managed, asta înseamnă că trebuie să planificați două intervenții: una pentru hipervizoare, alta — pe lot — pentru guest-urile administrate.

Recomandări concrete

Pentru oricine operează infrastructură Linux în producție, în special hosting multi-tenant:

  1. Verificați chiar acum dacă mitigarea pe care credeați că ați aplicat-o (/etc/modprobe.d/...) chiar funcționează. Comanda modinfo algif_aead | grep filename vă dă răspunsul în 2 secunde.
  2. Aplicați mitigarea corectă prin grubby pe toate hipervizoarele, în următoarea fereastră de mentenanță. Reboot-ul este obligatoriu iar mitigarea nu rupe nimic funcțional.
  3. Urmăriți publicarea kernel-urilor patch-uite:
  4. Comunicați cu clienții care au VM-uri neadministrate. Exploit-ul este public și trivial. Un client cu un WordPress vulnerabil are deja un vector de RCE → root în VM-ul propriu.
  5. Auditați infrastructura — am pregătit un script bash care scanează multiple hipervizoare prin SSH și raportează status-ul mitigării, versiunea kernel-ului față de pragul patch-uit, prezența mitigării greșite cu modprobe.d, și consumatorii activi de AF_ALG. Disponibil la cerere.

Concluzie

CVE-2026-31431 nu este o vulnerabilitate exotică sau dificil de exploatat — este o eroare de logică simplă, cu un PoC de 732 de octeți, prezentă în orice kernel Linux din ultimii 9 ani. Pentru un sysadmin individual cu un VPS personal este un patch obișnuit. Pentru un operator de hosting cu zeci sau sute de hipervizoare KVM și mii de VM-uri client, este un eveniment care trebuie gestionat cu disciplină: audit, mitigare, comunicare, patching.

Iar lecția cu adevărat importantă este meta: când o vulnerabilitate critică apare, primul instinct este să copiați comanda din primul thread oss-security găsit. Dar comanda funcționează diferit pe distribuții diferite, iar diferența poate fi între „protejat” și „fals protejat”. Verificați întotdeauna că mitigarea aplicată chiar a făcut ceea ce credeați.

Operăm infrastructură de hosting RHEL + KVM cu management complet. Dacă aveți întrebări despre cum afectează acest CVE setup-ul vostru, sau dacă doriți auditarea hipervizoarelor, contactați-ne.

Resurse: