CVE-2026-46333 (ssh-keysign-pwn): a patra vulnerabilitate de kernel Linux în trei săptămâni – ce trebuie să știți

In 14 mai 2026, echipa Qualys Security Advisory a publicat CVE-2026-46333, o vulnerabilitate de divulgare a informațiilor în kernelul Linux, cunoscută public sub numele ssh-keysign-pwn. Bug-ul permite unui utilizator local fără privilegii să citească fișiere deținute de root — în special cheile private SSH ale serverului și baza de date /etc/shadow — fără să escaladeze efectiv la root.

Scorul CVSS este 7,8 (Ridicat). Un proof-of-concept public funcțional există deja pe GitHub. Aceasta este a patra problemă serioasă de kernel Linux care apare în doar trei săptămâni, după Copy Fail (29 aprilie), Dirty Frag (7 mai) și Fragnesia (13 mai).

Dacă administrați servere CloudLinux 8 LTS, CloudLinux 9, CloudLinux 10, AlmaLinux 9 sau AlmaLinux 10 — sau orice distribuție Linux modernă pe care utilizatori locali (chiriași, clienți de hosting partajat, conturi de dezvoltare) au acces shell — citiți mai departe. Soluția temporară este o singură comandă și se aplică fără repornire.

Ce este, mai exact, această vulnerabilitate?

Pentru a înțelege ssh-keysign-pwn fără a deveni dezvoltator de kernel, trebuie să clarificăm trei componente.

1. ptrace și verificarea „dumpability”

ptrace(2) este apelul de sistem prin care un proces poate inspecta sau controla un alt proces — așa funcționează gdb -p, strace -p și perf trace. Pentru că ptrace ar permite, fără limite, oricui să citească memoria oricărui alt proces, kernelul are o verificare de acces: ptrace_may_access(). Această verificare folosește un flag numit dumpable — adică, în mare, „acest proces poate fi inspectat de cineva fără privilegii?”. Procesele SUID-root au în mod normal dumpable = 0, ceea ce înseamnă că un utilizator obișnuit nu le poate atașa.

2. pidfd_getfd(2) — clonarea descriptorilor de fișier

Linux 5.6 a introdus pidfd_getfd(2), un apel de sistem care permite unui proces să copieze un descriptor de fișier deschis dintr-un alt proces. Verificarea de permisiune folosește aceeași ptrace_may_access() — dacă ai voie să ataci procesul cu ptrace, ai voie să-i furi descriptorii deschiși.

3. „Race”-ul pe calea de ieșire

Când un proces se termină, kernelul execută o serie de pași în funcția do_exit. Printre aceștia:

1. Detașarea descriptorului de memorie al procesului (mm devine NULL).
2. Închiderea tabelei de descriptori de fișier deschise.

Bug-ul se află între acești doi pași. După ce mm devine NULL, dar înainte ca descriptorii de fișier să fie închiși, ptrace_may_access() sare peste verificarea dumpable — pentru că „nu există memorie de protejat”. Pentru o fereastră îngustă de timp, un atacator fără privilegii poate apela pidfd_getfd(2) și să copieze descriptori deschiși ai unui proces SUID-root care tocmai se opreste.

De ce contează SUID-ul

Țintele perfecte sunt binarele SUID-root care deschid fișiere sensibile ca parte normală a execuției lor:

• /usr/libexec/openssh/ssh-keysign — citește /etc/ssh/ssh_host_*_key (cheile private SSH ale serverului) la pornire. Există ca SUID-root tocmai pentru a putea citi acele fișiere când este invocat de un utilizator neprivilegiat în contextul autentificării host-based SSH.
• /usr/bin/chage — citește /etc/shadow pentru a verifica și modifica informațiile de expirare a parolei.

Exploit-ul, simplificat:

1. Atacatorul lansează ssh-keysign sau chage (sunt binare obișnuite, oricine le poate executa).
2. Binarul, ca SUID-root, deschide fișierul protejat și începe să iasă.
3. În fereastra de „race”, atacatorul apelează pidfd_getfd(2) pe procesul care iese, clonează descriptorul deja deschis al /etc/shadow sau al cheii SSH, și citește conținutul prin propriul său descriptor de fișier neprivilegiat.

Rezultatul: cheia privată SSH a serverului dumneavoastră și/sau întreaga bază de date cu hash-uri de parole sunt în mâinile atacatorului. Cu cheia SSH host a serverului, un atacator poate ataca de tip man-in-the-middle clienți SSH care se conectează la server. Cu /etc/shadow, poate executa brute-force offline asupra parolelor tuturor utilizatorilor.

Cine este afectat?

Bug-ul a fost introdus în kernelul Linux upstream în versiunea v4.10-rc1 (2017, commit bfedb589). Asta înseamnă că aproape orice distribuție Linux modernă cu kernel ≥ 4.10 are bug-ul în cod.

Totuși, exploatarea prin proof-of-concept-ul public necesită pidfd_getfd(2), care a apărut în Linux 5.6 (2020). Asta face diferența între „vulnerabil în teorie” și „spart astăzi cu un script de pe GitHub”:

Pentru CloudLinux 7h și CloudLinux 8, cursa este prezentă în cod, iar comunitatea de securitate lucrează deja la un PoC adaptat care folosește ptrace_attach direct, fără pidfd_getfd. Tratați-le ca pe niște obiective de patching cu prioritate normală — vor fi corectate pe aceeași cronologie.

Solutii — ce puteți aplica chiar acum

Există trei solutii de limitare. Aplicați-o pe prima pentru acoperire la nivel de host. Aplicați-le pe celelalte ca apărare în adâncime sau dacă prima nu este posibila.

Varianta 1 (recomandată) — pe CloudLinux: kernel.user_ptrace=0

CloudLinux expune un sysctl propriu, kernel.user_ptrace, care controlează dacă utilizatorii fără privilegii pot folosi ptrace. Setarea pe 0 blochează problema la nivel de kernel pentru orice cont de pe gazdă.

# Aplicare imediată (fără repornire)
sudo sysctl -w kernel.user_ptrace=0

# Persistare după repornire
echo 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-cve-2026-46333.conf
sudo sysctl --system

# Revenire (după instalarea kernelului patch-uit)
sudo rm /etc/sysctl.d/99-cve-2026-46333.conf
sudo sysctl -w kernel.user_ptrace=1

Efecte secundare: utilizatorii fără privilegii nu mai pot folosi gdb -p, strace -p sau perf trace --pid asupra propriilor procese. Pe hosting partajat, asta este perfect acceptabil. Pe servere de dezvoltare sau CI unde echipele atașează debuggere, planificați o discuție cu utilizatorii înainte de a aplica.

Varianta 1 (recomandată) — pe distribuții non-CloudLinux: kernel.yama.ptrace_scope=3

Pe Debian, Ubuntu, AlmaLinux/Rocky vanilla și alte distribuții fără sysctl-ul specific CloudLinux, modulul de securitate Yama oferă echivalentul:

# Aplicare imediată
sudo sysctl -w kernel.yama.ptrace_scope=3

# Persistare după repornire
echo 'kernel.yama.ptrace_scope = 3' | sudo tee /etc/sysctl.d/99-cve-2026-46333.conf
sudo sysctl --system

Valoarea 3 interzice complet ataşarea ptrace pentru procesele fără CAP_SYS_PTRACE și este „sticky” până la repornire — nici măcar userul  root nu o poate repune înapoi fără reboot.

Varianta 2 — CageFS (pe CloudLinux)

Dacă rulați CloudLinux cu CageFS activat (configurația implicită pe hosting partajat), chiriașii (caged tenants) sunt deja protejați. Binarele SUID /usr/bin/chage și /usr/libexec/openssh/ssh-keysign nu sunt prezente în vizualizarea filesystem-ului din „cage”, astfel încât exploit-ul eșuează la execvp(...) înainte ca vreun syscall ptrace să fie emis.

Atenție: CageFS protejează doar utilizatorii din „cage”. Root-ul gazdei și conturile administrative care nu in „cage” sunt în continuare expuse dacă un atacator obține shell pentru un astfel de cont.

Varianta 3 — ștergerea bit-ului SUID de pe binarele cunoscute

Doar dacă varianta 1 nu este posibilă (ex: utilizatori legitimi au nevoie de ptrace neprivilegiat) și CageFS nu este activ:

sudo chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null
sudo chmod u-s /usr/bin/chage

# Verificare: rândul ar trebui să înceapă cu -rwxr-xr-x, nu -rwsr-xr-x
ls -l /usr/libexec/openssh/ssh-keysign /usr/bin/chage

Această varianta nu acoperă întreaga clasă de bug. chage și ssh-keysign sunt țintele publicate, dar orice binar SUID-root care deschide secrete la pornire poate fi vulnerabil. Atenuarea 1 închide calea kernelului la nivel global; varianta 3 nu.

În plus:

• ssh-keysign este invocat numai de ssh(1) când clientul are HostbasedAuthentication yes. Dacă serverul dumneavoastră nu folosește autentificarea SSH host-based (rar în hosting), ștergerea bitului SUID nu va afecta nimic.
• Bit-ul SUID de pe chage permite unui utilizator obișnuit să își interogheze și să-și schimbe propria expirare a parolei. Ștergerea înseamnă că doar root mai poate rula chage. Folosirea administrativă rămâne neafectată.

Patch-uri permanente — calendarul lansării

Pentru AlmaLinux 9/10, dacă doriți să luați kernelul din repository-ul testing înainte de promovarea în production:

# AlmaLinux 10
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm
dnf update 'kernel*'
reboot
uname -r
dnf config-manager --disable almalinux-testing

# AlmaLinux 9 — schimbă URL-ul la pachetul de release-testing pentru EL9

Odată ce patch-ul ajunge în repository-ul de production, un dnf update 'kernel*' && reboot simplu este suficient.

KernelCare va publica un livepatch ce nu necesită repornire, mai întâi pe canalul de testing și apoi pe cel principal. Pentru parcuri mari de servere unde repornirile multiple într-o singură lună sunt o problemă operațională serioasă, KernelCare este alternativa pragmatică — patch-ul se aplică pe kernelul în execuție, fără fereastră de mentenanță.

Cum verificați că serverul este protejat

# Versiunea kernelului în execuție
uname -r

# Sysctl-ul de atenuare (CloudLinux)
sysctl kernel.user_ptrace

# Sysctl-ul de atenuare (Yama, alte distribuții)
sysctl kernel.yama.ptrace_scope

# Pentru sistemele cu KernelCare
kcarectl --patch-info | grep CVE-2026-46333

Un rezultat de kernel.user_ptrace = 0 sau kernel.yama.ptrace_scope = 3, plus o linie non-vidă în output-ul KernelCare (dacă-l folosiți), înseamnă că sunteți protejat.

Patru vulnerabilități în trei săptămâni — un model îngrijorător

Această CVE este a patra problemă serioasă de kernel Linux în trei săptămâni:

• 29 aprilie 2026 — Copy Fail (XFRM/ESP)
• 7 mai 2026 — Dirty Frag (XFRM/ESP)
• 13 mai 2026 — Fragnesia (XFRM/ESP)
• 14 mai 2026 — ssh-keysign-pwn (ptrace) — această CVE

Primele trei formau un lanț de escaladare a privilegiilor în subsistemul XFRM/ESP. ssh-keysign-pwn este diferit ca natură (divulgare de informații, nu escaladare directă), dar coexistă cu același tablou: ritmul publicării vulnerabilităților de kernel se accelerează, iar fiecare reclamă o intervenție din partea administratorului.

Pentru orice echipă care administrează mai mult de câteva servere, patru ferestre de mentenanță cu repornire într-o singură lună sunt scumpe operațional. Aici sunt două principii pe care le aplicăm pe infrastructura HostX și pe care le recomandăm:

1. Solutiile la nivel de sysctl sunt arme defensive subutilizate. kernel.user_ptrace=0 și kernel.yama.ptrace_scope=3 opresc clase întregi de exploit-uri ptrace fără să atingă codul. Sunt reversibile, fără reboot, și ar trebui să fie parte din configurația de bază a oricărui server unde utilizatorii fără privilegii nu au o nevoie operațională de ptrace.
2. Livepatching nu mai este un lux. Pentru parcuri de servere care găzduiesc clienți cu SLA, fiecare repornire este o întrerupere. KernelCare și echivalentele sale (kpatch, Ksplice) transformă fereastra „patch + reboot” într-o aplicare invizibilă. Costul lor lunar este, în majoritatea cazurilor, mai mic decât costul orelor de mentenanță planificate și al SLA-urilor încălcate.

Ce facem la HostX

Pe toată infrastructura administrată HostX (hosting partajat și VPS administrate), atenuarea 1 a fost aplicată în câteva ore de la publicarea CVE-ului. CageFS este în continuare activ pe toate platformele de hosting partajat. Kernelurile patch-uite sunt în prezent în testare în mediul nostru de staging și vor fi implementate pe servere în următoarele zile, cu repornire programată în ferestrele standard de mentenanță. Fiecare client afectat de o repornire va primi o notificare separată.

Pentru clienții cu servere neadministrate sau servere dedicate auto-administrate: vă recomandăm să aplicați imediat atenuarea descrisă mai sus. Echipa noastră de suport este disponibilă pentru asistență, gratuit, prin ticket.

Referințe

• NVD — CVE-2026-46333
• Fix-ul upstream — commit 31e62c2ebbfd
• Advisory CloudLinux
• Advisory AlmaLinux
• Proof-of-concept public (GitHub)