L'azienda Qualys ha scoperto una vulnerabilità critica (CVE-2024-6387) in OpenSSH che consente l'esecuzione remota di codice con privilegi di root senza autenticazione. La vulnerabilità, conosciuta con il nome in codice regreSSHion, si manifesta nella configurazione predefinita a partire dalla versione OpenSSH 8.5 su sistemi con la libreria standard Glibc.
La possibilità di eseguire un attacco è stata dimostrata su un sistema a 32 bit con Glibc con la protezione ASLR (randomizzazione dello spazio degli indirizzi) abilitata. Per un attacco riuscito in condizioni di laboratorio sono stati necessari 6-8 ore, durante le quali si server stabilivano continuamente connessioni con la massima intensità consentita nella configurazione di sshd. L'esecuzione dell'attacco è semplificata e richiede meno tempo su sistemi senza ASLR o in distribuzioni che utilizzano una versione modificata di OpenSSH, in cui la ri-randomizzazione di ASLR è disabilitata per ogni connessione. Si è deciso di non pubblicare un prototipo funzionante dell'exploit fino a quando la vulnerabilità non sarà stata completamente risolta, ma è disponibile una descrizione sufficientemente dettagliata della vulnerabilità, il che rende l'emergere di exploit di terze parti solo una questione di tempo.
Non si esclude la possibilità di attacchi anche su sistemi a 64 bit, ma al momento non esiste un exploit funzionante per tali sistemi. Si prevede che un attacco su sistemi a 64 bit richiederà molto più tempo, ma non più di una settimana. OpenSSH su OpenBSD non è suscettibile al problema, poiché in questo sistema dal 2001 è utilizzato un meccanismo di protezione che blocca classi di attacco simili. In altri sistemi basati su librerie standard diverse da Glibc, è teoricamente possibile adattare il metodo per eseguire un attacco (Qualys non ha ancora studiato questa questione).
La vulnerabilità è stata corretta nella versione di OpenSSH 9.8 pubblicata oggi (patch). È possibile seguire la pubblicazione degli aggiornamenti dei pacchetti nelle distribuzioni sulle pagine: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch e FreeBSD. Come soluzione temporanea per bloccare la vulnerabilità, è possibile impostare il parametro "LoginGraceTime=0" nel file sshd_config; disattivare il timeout faciliterà l'avvio di un attacco di denial of service quando si stabiliscono molteplici connessioni che superano i limiti definiti tramite il parametro MaxStartups.
Uno dei segnali di un tentativo di attacco è la comparsa nel log di un numero elevato di registrazioni "Timeout before authentication".
La vulnerabilità è emersa a seguito di un cambiamento regressivo incluso nella versione di OpenSSH 8.5, che porta a una condizione di corsa nel codice di gestione dei segnali in sshd. La regressione ha comportato l'interruzione della protezione contro una vecchia vulnerabilità CVE-2006-5051, che si manifestava fino alla versione OpenSSH 4.4 (anno 2006) ed era di natura teorica.
Durante lo sviluppo di OpenSSH 8.5, è stato erroneamente rimosso il blocco "#ifdef DO_LOG_SAFE_IN_SIGHAND" dalla funzione sigdie(), che viene chiamata direttamente dal gestore SIGALRM.
Il gestore di SIGALRM viene chiamato in sshd in modalità asincrona se il cliente non ha eseguito l'autenticazione entro il tempo limite di connessione (LoginGraceTime, di default 120 secondi). L'attacco si basa sul fatto che il gestore del segnale chiama funzioni non sicure durante l'elaborazione asincrona dei segnali, come syslog(). La funzione syslog() in Glibc non è progettata per l'uso in gestori di segnali eseguiti in modo asincrono, poiché chiama funzioni malloc() e free(). L'attivazione del segnale SIGALRM, che interrompe l'esecuzione di un determinato codice in sshd, può portare a una violazione dello stato di esecuzione, e l'obiettivo dell'exploit è creare condizioni per interrompere il codice necessario al momento opportuno. La vulnerabilità non influisce su OpenBSD, poiché in esso, invece di syslog(), dal gestore del segnale SIGALRM viene chiamata la funzione syslog_r(), appositamente creata per esecuzioni asincrone.
Fonte: opennet.ru
