Una vulnerabilità soprannominata *sshole può consentire l’accesso via SSH ad alcuni account Linux configurati per rifiutare l’autenticazione con password. Il problema riguarda OpenSSH su distribuzioni basate sulla libreria musl, come Alpine Linux, quando ricorrono precise condizioni nella configurazione del server.
La falla è stata corretta in OpenSSH 10.6p2. Per gli amministratori dei sistemi interessati, l’aggiornamento è la misura principale; in alternativa temporanea è possibile disabilitare l’autenticazione SSH con password.
Come funziona la vulnerabilità *sshole
Sui sistemi Linux un account può essere escluso dall’accesso con password inserendo un asterisco (*) al posto dell’hash nel file /etc/shadow. Non essendo un hash valido, in condizioni normali nessuna password dovrebbe permettere il login su quell’account.
Il difetto nasce dall’interazione tra OpenSSH e la funzione crypt() della libreria musl. Una modifica introdotta in OpenSSH nel 2016, pensata per evitare che i tempi di risposta rivelassero l’esistenza di determinati utenti, porta il server a calcolare comunque l’hash della password anche per gli account senza un hash utilizzabile.
Con musl, però, crypt() restituisce anch’essa un asterisco quando il calcolo fallisce. Il caso indicato dal ricercatore riguarda password più lunghe del limite di 256 byte: il risultato restituito può così coincidere con l’asterisco memorizzato per l’account bloccato, facendo riuscire il confronto eseguito da OpenSSH.
Non si tratta di un aggiramento generalizzato delle password: la falla non consente di entrare negli account che hanno un hash valido memorizzato.
Quali sistemi possono essere colpiti
L’attacco richiede una combinazione specifica di fattori. OpenSSH deve essere in esecuzione su una distribuzione che usa musl, tra quelle citate rientrano Alpine Linux, OpenWrt, Buildroot e Yocto. Inoltre PAM deve essere disabilitato, l’autenticazione SSH tramite password deve restare attiva e almeno un account deve avere l’asterisco come hash della password.
Tra i requisiti riportati c’è anche la presenza di un altro account con un hash valido. I sistemi che usano glibc, inclusi Debian, Ubuntu e Fedora, non risultano vulnerabili secondo il resoconto, così come le installazioni che usano l’autenticazione PAM.
Il ricercatore Ozgun Kultekin segnala un caso particolarmente delicato nelle immagini cloud ufficiali Alpine Linux per AWS e Azure: l’account predefinito alpine sarebbe interessato e dispone di privilegi doas senza password. In quella configurazione, un accesso riuscito potrebbe portare all’ottenimento dei privilegi di root.
Aggiornamento e mitigazioni disponibili
La correzione è inclusa in OpenSSH 10.6p2. Su Alpine Linux, l’indicazione è aggiornare il pacchetto OpenSSH con il comando apk upgrade openssh.
Chi non può applicare subito l’aggiornamento può disabilitare l’autenticazione SSH con password impostando PasswordAuthentication no nella configurazione del server SSH e riavviando il servizio. Questa misura rimuove una delle condizioni necessarie allo sfruttamento della falla.
È possibile anche controllare i registri di autenticazione alla ricerca di accessi con password verso account che non dovrebbero accettarla. Su Alpine Linux, il comando grep “Accepted password” /var/log/messages mostra i login SSH con password andati a buon fine. Un accesso di questo tipo per l’utente alpine, se il relativo campo in /etc/shadow contiene un asterisco, può essere un segnale di sfruttamento.
FAQ
Debian e Ubuntu sono vulnerabili a *sshole?
No. Il problema descritto riguarda le distribuzioni che usano musl; Debian e Ubuntu usano glibc e non sono indicati come vulnerabili.
La falla permette di indovinare qualsiasi password SSH?
No. Non aggira le password degli account con un hash valido. Colpisce invece alcune configurazioni in cui l’asterisco viene usato per impedire i login con password.
Qual è la soluzione più immediata?
L’aggiornamento a OpenSSH 10.6p2 è la correzione disponibile. In attesa dell’update, disattivare l’autenticazione SSH tramite password riduce il rischio perché elimina un requisito dell’attacco.
Considerazioni finali
La gravità di *sshole sta nel fatto che sfrutta una configurazione usata proprio per negare l’accesso con password. Non è una falla universale: dipende da musl, dall’assenza di PAM e da altre condizioni ben definite. Proprio questa delimitazione, però, non riduce l’urgenza per chi amministra server Alpine Linux esposti in rete.
La disponibilità di una correzione in OpenSSH 10.6p2 rende la risposta piuttosto netta: aggiornare è preferibile a considerare sufficiente il blocco ottenuto con l’asterisco in /etc/shadow. Dove l’update deve attendere, disabilitare PasswordAuthentication interviene direttamente sulla condizione che rende possibile l’accesso.