Una stringa di password da 257 a 1.024 byte bastava per accedere tramite SSH a determinati account Linux configurati senza password. Il problema, divulgato il 5 novembre 2026, riguarda i server OpenSSH che utilizzano la libreria musl e soddisfano una specifica combinazione di impostazioni; OpenSSH ha pubblicato la correzione 10.6p2.
La vulnerabilità, denominata *sshole, è stata scoperta e segnalata dal ricercatore Özgün Kültekin, di Wakefield. Alpine Linux ha confermato che i suoi pacchetti erano interessati e ha pubblicato aggiornamenti per le versioni attuali e precedenti. Negli avvisi pubblicati quel giorno non era stato assegnato un identificativo CVE al problema.
Una password lunga poteva corrispondere all’asterisco di /etc/shadow
In Linux, è possibile impedire l’accesso tramite password a un account inserendo un asterisco (*) nel campo corrispondente di /etc/shadow. Negli account interessati, OpenSSH confrontava il risultato del calcolo della password inviata con quel campo. Il problema si verificava quando il server effettuava questo controllo senza PAM e la funzione crypt() di musl riceveva una password troppo lunga.
Secondo l’avviso di Alpine, musl restituisce * come indicatore di errore quando la password supera i 256 byte. Poiché lo stesso carattere compare nel campo di un account senza password, i risultati potevano corrispondere e sshd accettava l’accesso. Perché ciò accadesse, l’aggressore doveva conoscere il nome di un account con quel campo e inviare una password da 257 a 1.024 byte.
Alpine descrive l’attacco come possibile con una sola connessione, senza dover ripetere i tentativi. La distribuzione segnala inoltre che il computer deve avere almeno un altro account locale con un hash della password che inizi con $5$ o $6$. È sufficiente un account con uno di questi hash perché gli account senza password siano esposti, se sussistono anche le altre condizioni.
Il problema non consente di aggirare l’autenticazione degli account che hanno un hash valido. Riguarda il percorso di verifica delle password senza PAM e gli account il cui campo memorizzato è *; non è un bypass generale di tutte le password SSH.
Le condizioni che espongono un server
Alpine elenca quattro requisiti che devono verificarsi contemporaneamente: eseguire il pacchetto openssh-server, compilato senza PAM, oppure openssh-server-pam con UsePAM no; avere abilitato PasswordAuthentication; avere un account il cui campo della password è *; e disporre di almeno un account locale con un hash $5$ o $6$.
L’opzione di autenticazione tramite password è abilitata per impostazione predefinita nella configurazione descritta per Alpine. Rientrano nello scenario anche gli account creati per autenticarsi solo con una chiave SSH, quelli che usano usermod -p '*' e alcuni utenti provenienti da servizi di directory tramite musl-nscd, che potrebbero non avere una voce in /etc/shadow.
Nell’immagine di base di Alpine, dalla versione 3.16 circa, l’account root compare come root:*. L’impostazione predefinita di OpenSSH, PermitRootLogin prohibit-password, impedisce l’accesso diretto a root tramite password. Tuttavia, questa protezione non impedisce a un aggressore di raggiungere root se prima accede a un altro account vulnerabile che consente di elevare i privilegi, ad esempio tramite doas.
L’avviso di Alpine include tra le installazioni interessate le versioni dalla 3.21 alla 3.24 e edge sottoposte a verifica, oltre alle versioni dalla 3.16 alla 3.20, che non ricevono più aggiornamenti regolari. Il problema non riguarda solo Alpine: Kültekin ha indicato anche OpenWrt, Buildroot e Yocto come sistemi basati su musl da controllare. In OpenWrt, il server SSH predefinito è Dropbear, che non è interessato; il rischio sussiste se si installa OpenSSH.
Sono esclusi i sistemi che usano glibc, come Debian, Ubuntu e Fedora, quelli che eseguono l’autenticazione tramite PAM con UsePAM yes e le installazioni con PasswordAuthentication no. Il problema non riguarda neppure i container che non eseguono sshd, gli account bloccati con ! nel campo della password né i computer senza account con gli hash del tipo indicato. Alpine aggiunge che le sue immagini cloud configurate tramite cloud-init impostano PasswordAuthentication no.
Immagini tiny-cloud: dal primo avvio all’accesso root
Il caso più delicato descritto da Alpine riguarda le immagini ufficiali tiny-cloud nei formati qcow2, VHD e AMI, dalle versioni 3.18.11 alla 3.24.3. Includono un utente alpine senza password, autorizzato a usare doas senza password. Al primo avvio non sono vulnerabili tramite questo vettore, ma lo diventano quando nel sistema è presente un hash $6$.
L’hash può comparire quando un amministratore imposta una password per la console o quando i dati utente aggiungono un account con hashed_passwd. Una volta soddisfatte le condizioni, l’aggressore può accedere come alpine e usare doas per diventare root. Alpine specifica che le immagini create a partire dalle versioni 3.21.10, 3.22.8, 3.23.8 e 3.24.4 includono già il pacchetto corretto; le immagini delle versioni precedenti richiedono l’aggiornamento di ogni istanza in esecuzione o la disattivazione dell’autenticazione tramite password.
L’avviso della distribuzione spiega che la correzione è stata pubblicata anche per le versioni precedenti: la versione 3.21 ha raggiunto la fine del supporto il 1° novembre 2026, ma Alpine ha distribuito pacchetti corretti a partire dalla 3.16. Per le versioni indicate, le versioni di OpenSSH corrette sono 10.3_p1-r2 nella 3.24, 10.2_p1-r1 nella 3.23, 10.0_p1-r11 nella 3.22, 9.9_p2-r1 nella 3.21, 9.7_p1-r6 nella 3.20, 9.6_p1-r3 nella 3.19, 9.3_p2-r4 nella 3.18, 9.1_p1-r7 nella 3.17 e 9.0_p1-r6 nella 3.16. Per edge, la versione indicata è 10.6_p2-r0.
OpenSSH e Alpine pubblicano la correzione
OpenSSH 10.6p2 impedisce a sshd di accettare questa corrispondenza. I pacchetti delle versioni stabili di Alpine includono una patch per lo stesso problema. L’aggiornamento del pacchetto non sostituisce il processo sshd già in esecuzione: Alpine chiede di riavviare il servizio dopo l’aggiornamento. La raccomandazione è eseguire apk upgrade -U -a e poi rc-service sshd restart.
Se non è possibile installare subito la patch, Alpine consiglia di disattivare l’autenticazione tramite password impostando PasswordAuthentication no e riavviando sshd. La distribuzione avverte che prima bisogna verificare che l’accesso con chiave SSH funzioni e lasciare aperta la sessione corrente finché non si è provata una nuova connessione. Per le installazioni che non possono aggiornare o applicare questa modifica, CERT-FR consiglia di disattivare il servizio SSH.
“set PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.”
— Damien Miller, progetto OpenSSH
CERT-FR ha pubblicato il primo avviso il 5 novembre 2026 e ha classificato il rischio come un bypass della policy di sicurezza. Nel suo riepilogo considera banale lo sfruttamento quando si verificano le condizioni e chiede di verificare se i sistemi sono configurati in modo vulnerabile. L’ente indica inoltre come misura di mitigazione preferibile la disattivazione dell’autenticazione tramite password finché non è possibile installare la correzione.
Cosa controllare nei log
Alpine chiede di cercare in /var/log/messages le righe di sshd contenenti il testo Accepted password per account che non dovrebbero consentire l’autenticazione tramite password, come alpine, root o gli utenti con chiave pubblica. Raccomanda inoltre di controllare l’uso di doas, gli account creati di recente, i file e le chiavi autorizzate sui computer esposti.
CERT-FR propone di individuare innanzitutto gli account il cui campo in /etc/shadow è * e verificare se esistono registrazioni di accessi accettati per tali account. Se non è possibile escludere che si sia verificato un accesso, Alpine indica di considerare il computer compromesso. Nelle immagini vulnerabili, un accesso a alpine seguito dall’uso di doas può implicare l’accesso root.
Kültekin riconduce l’origine del problema a una modifica di OpenSSH del 2016, volta a correggere l’enumerazione degli utenti associata a CVE-2016-6210. Per evitare che le differenze nei tempi di risposta rivelassero se un nome utente fosse valido, OpenSSH ha iniziato a calcolare le password anche per gli account senza un hash utilizzabile. Il problema è rimasto in questa interazione con musl, la cui funzione crypt() restituisce l’asterisco quando viene superato il limite di lunghezza.
Il ricercatore racconta di aver individuato il problema con agenti IA che hanno eseguito circa 17.600 test di autenticazione, usando diverse configurazioni di OpenSSH, hash malformati e password troppo lunghe. Damien Miller ha dichiarato che il team di OpenSSH è venuto a conoscenza del problema all’inizio di quella settimana e ha pubblicato rapidamente la correzione. The Hacker News riporta inoltre la sua spiegazione secondo cui il progetto considera gli embargo prolungati un rischio, perché gli agenti IA hanno individuato autonomamente vulnerabilità dello stesso tipo, a volte nel giro di poche ore.
Nella pagina di *sshole, Kültekin descrive diversi indizi precedenti che si erano avvicinati al problema, tra cui una modifica in Debian relativa al valore restituito da glibc e una revisione di sicurezza che aveva corretto pick_salt() quattro giorni prima della sua scoperta. Non afferma che quegli episodi avessero individuato la vulnerabilità di sshd. Alla data degli avvisi del 5 novembre, il problema era ancora privo di identificativo CVE e non erano stati segnalati attacchi reali.
Fonti: BleepingComputer, RedesZone, alpinelinux.org, Alpine Linux, Özgün Kültekin / Wakefield, CERT-FR, The Hacker News
