SSHole — una vulnerabilità che consente di connettersi via SSH senza password in sistemi con Musl

Gli sviluppatori di OpenSSH hanno pubblicato un aggiornamento urgente di OpenSSH 10.6p2, che introduce una protezione contro una vulnerabilità critica (CVE non assegnato), soprannominata ‘SSHole’, che consente di bypassare l'autenticazione. Nei sistemi con la libreria Musl, la vulnerabilità permette di accedere a un utente per il quale non è impostata una password, inserendo qualsiasi password di oltre 256 caratteri. Il problema riguarda le distribuzioni Linux che utilizzano la libreria standard musl ma non utilizzano PAM (Pluggable Authentication Modules), come OpenWRT, Alpine, Buildroot e Yocto. Riveste particolare pericolo il fatto che spesso l'accesso tramite password per l'utente root è bloccato, consentendo a chiunque di connettersi da remoto con diritti di amministratore.

L'errore che porta alla vulnerabilità non è nel codice di OpenSSH, ma viene sfruttato tramite sshd. Data la serietà del problema, nella versione OpenSSH 10.6p2 è stata proposta una soluzione temporanea per bloccare la vulnerabilità. Ai proprietari di sistemi colpiti si consiglia di non aspettare aggiornamenti e di disabilitare immediatamente l'autenticazione tramite password usando il parametro «PasswordAuthentication no» in /etc/ssh/sshd_config o di disabilitare completamente SSH.

Il problema non si manifesta nei sistemi diversi da Linux e negli ambienti Linux basati su glibc, nonché nei sistemi che utilizzano PAM per l'autenticazione tramite password. La correzione è già disponibile in Alpine e OpenWRT.

La vulnerabilità è legata a un'interazione errata tra OpenSSH e la funzione crypt() di musl. Per proteggere dall'identificazione dell'esistenza di utenti tramite l'analisi delle differenze nei tempi di elaborazione delle richieste, dal 2016 OpenSSH utilizza, per controllare gli account senza password, una procedura standard di verifica della password: chiama la funzione «crypt(password fornita, sale)» con la sale di un altro utente avente un hash di password valido, confrontando poi l'hash restituito dalla funzione crypt con il valore del campo contenente l'hash della password.

Tuttavia, in musl, la funzione crypt() per gli hash SHA-512 restituisce il carattere «*» se la lunghezza della password fornita supera i 256 byte (limite introdotto nel 2012 per proteggere da attacchi DoS, poiché l'invio di valori maggiori comporta un alto carico sulla CPU). Lo stesso carattere è utilizzato nel campo contenente l'hash della password in «/etc/shadow» per indicare gli account per i quali l'autenticazione tramite password è bloccata.

Di conseguenza, un attaccante in grado di connettersi a un server SSH può accedere a qualsiasi account che ha il simbolo "*" nel campo della password in "\/etc\/shadow", inviando una stringa di lunghezza compresa tra 257 e 1024 byte. Il problema interessa numerose immagini Docker esistenti, create utilizzando Alpine Linux, così come le immagini Alpine di base per i sistemi cloud AWS e Azure, in cui l'utente root ha un simbolo "*" al posto dell'hash della password.

È interessante notare che inizialmente, nelle immagini Docker ufficiali che utilizzano Alpine, dal 2015 veniva impostata una password root vuota e, dopo che questo fatto è stato scoperto, anziché l'hash della password è stato utilizzato il simbolo "!". Tuttavia, la sua presenza bloccava l'accesso tramite chiavi SSH, quindi dal 2022 il simbolo per bloccare l'accesso tramite password è stato cambiato in "*".

Fonte: opennet.ru