Il 1° luglio i ricercatori di Qualys hanno annunciato regreSSHion, registrata come CVE-2024-6387: una vulnerabilità nel server OpenSSH che permette, senza autenticazione, di eseguire codice come root sui sistemi Linux basati su glibc. Il nome gioca sulla parola regressione. È il ritorno di una falla corretta nel 2006, la CVE-2006-5051, reintrodotta per errore nell’ottobre 2020 con una modifica al codice di registrazione.
Il meccanismo è questo. Quando un client non completa l’autenticazione entro il tempo massimo, impostato da LoginGraceTime a 120 secondi per default, sshd riceve un segnale SIGALRM. Il gestore di quel segnale richiama funzioni come syslog(), che in quel contesto non sono sicure. Sfruttando la race condition, un attaccante può corrompere la memoria ed eseguire codice come root.
Non è un attacco da un minuto. In laboratorio, su un sistema a 32 bit, sono serviti circa 10.000 tentativi, cioè alcune ore di connessioni continue. Sui sistemi a 64 bit lo sfruttamento è considerato possibile ma più complesso, e i ricercatori non hanno mostrato un exploit funzionante. Con il tempo, però, gli exploit migliorano sempre.
Diciotto anni dopo
Sono vulnerabili le versioni dalla 8.5p1 alla 9.7p1 compresa, su Linux con glibc, e quelle precedenti alla 4.4p1 che non hanno mai ricevuto le correzioni per le vecchie falle. OpenBSD non è coinvolto. La correzione è in OpenSSH 9.8p1. Le scansioni di Internet contano circa 14 milioni di server OpenSSH potenzialmente vulnerabili esposti.
OpenSSH è uno dei progetti con la migliore reputazione di sicurezza in circolazione, e una falla sfruttabile da remoto nel suo server non si vedeva da molti anni. Che sia tornata proprio una vecchia conoscenza dice molto sull’importanza dei test di regressione, anche nei progetti più curati.
Aggiorna il pacchetto OpenSSH tramite la tua distribuzione: Debian, Ubuntu, RHEL, Fedora e le altre stanno pubblicando le versioni corrette. Se non puoi farlo subito, imposta LoginGraceTime 0 in sshd_config e riavvia il servizio. Eviti l’esecuzione di codice, ma un attaccante può esaurire le connessioni disponibili.
A lungo termine, la difesa migliore resta non esporre SSH a tutta Internet: limitane l’accesso a IP fidati o mettilo dietro una VPN, e blocca gli indirizzi con troppi tentativi falliti. Non dimenticare appliance e dispositivi basati su Linux che includono OpenSSH. Per quelli dovrai aspettare il produttore.
