SSHole: la falla di OpenSSH che apre Alpine con una password lunga

Il 5 novembre OpenSSH ha rilasciato d'urgenza la versione 10.6p2. Corregge una falla che lo scopritore, Özgün Kültekin di Wakefield, ha chiamato «*sshole»: su Alpine e sugli altri Linux costruiti sulla libreria musl, se il server SSH non usa PAM, una password qualsiasi fra 257 e 1.024 caratteri apre gli account che una password non ce l'hanno. Damien Miller, che mantiene OpenSSH, nella mail di rilascio scrive di averlo saputo il giorno prima. La sera stessa l'ACN l'ha classificata critica; il record della CVE-2026-123158 le dà 8,1 su 10.

Perché un asterisco apre la porta

In /etc/shadow un account che non ha una password ha un asterisco al posto dell'hash. Quando qualcuno prova una password, sshd la passa a crypt() e confronta il risultato con il contenuto del file. L'asterisco non ha un sale, e dal 2016, con OpenSSH 7.3, sshd ne prende in prestito uno da un altro account: serve a non far capire dai tempi di risposta quali utenti esistono.

musl rifiuta le chiavi più lunghe di 256 byte e, quando fallisce, restituisce un asterisco (sorgente). sshd confronta asterisco con asterisco e apre. Le password oltre i 1.024 caratteri le scarta sshd stesso, con un limite arrivato nella stessa versione del 2016 contro un altro attacco. La glibc di Debian, Ubuntu e Red Hat in caso di errore restituisce un'altra cosa, e con PAM quel confronto non si fa proprio.

La correzione è di poche righe: perché il confronto valga, il campo salvato deve avere almeno quattro caratteri. OpenSSH scrive di considerare la causa «fuori da sshd», cioè in musl.

Chi è esposto davvero

L'avviso di Alpine chiede quattro condizioni insieme. Due ce le ha ogni installazione che nessuno ha toccato: il pacchetto openssh-server di Alpine non usa PAM, e PasswordAuthentication vale yes. Poi serve un account con l'asterisco, e un altro con una password vera, cioè un hash che inizia con $5$ o $6$, da cui sshd prende il sale.

Hanno l'asterisco gli utenti creati con adduser -D per entrare solo con la chiave e l'utente alpine delle immagini cloud, che diventa root con doas senza password. Anche root ce l'ha, dalla 3.16 circa, ma finché resta l'impostazione predefinita PermitRootLogin prohibit-password con la password non entra. Gli account bloccati con ! sono fuori.

Un Alpine appena installato, senza nessuna password impostata, non è attaccabile: lo diventa quando qualcuno ne imposta una, magari solo per la console. L'immagine Docker alpine ufficiale sshd non ce l'ha, e le immagini cloud configurate con cloud-init hanno già le password spente. Restano le macchine virtuali e i server con Alpine, e i container in cui qualcuno ha installato sshd per entrarci.

Debian ha segnato la CVE come «unimportant». Uno scanner che guarda solo il numero di versione la troverà lo stesso su ogni server Debian, Ubuntu o Red Hat, dove non si può sfruttare.

Cosa si sa degli attacchi

Previdian, un'azienda che vende dati sulle minacce, ha visto il primo tentativo sui suoi sensori meno di nove ore dopo la pubblicazione della CVE; correzione e avviso di Alpine erano pubblici dalla mattina. La sua pagina al 6 novembre conta 13 tentativi da 9 indirizzi e avverte che non dicono se il bersaglio era vulnerabile né se l'attacco è riuscito. A Help Net Security il fondatore Ryan Dewhurst ha detto di aver confermato un accesso come root su un loro server esca con Alpine e OpenSSH. Non ha detto come fosse configurato, e con le impostazioni predefinite root con la password non entra.

La CISA, al 6 novembre, la falla nel suo catalogo delle vulnerabilità sfruttate non l'ha messa. Noi non aspetteremmo che lo faccia: la prova di concetto è pubblica nel repository del ricercatore, e per sfruttare la falla basta mandare una password lunga a un account che si conosce già, come alpine.

Cosa fare su un server Alpine

1. Aggiorna e riavvia: apk upgrade -U -a, poi rc-service sshd restart. L'aggiornamento del pacchetto non riavvia il processo, e finché non lo riavvii risponde il vecchio sshd.
2. Se non puoi aggiornare subito, spegni le password: echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf, poi sshd -t && rc-service sshd restart. Alpine legge quella cartella dalla 3.19; per le versioni precedenti l'avviso dà un comando sed. Lascia aperta la sessione mentre provi un nuovo accesso.
3. Verifica che valga: sshd -T | grep -i passwordauthentication deve rispondere passwordauthentication no.
4. Cerca nei log gli accessi che non dovevano esserci: grep 'Accepted password for' /var/log/messages. Un accesso con password come root, alpine o un utente che entra solo con la chiave è uno di quelli. Per Alpine, se non lo puoi escludere, la macchina va trattata come compromessa; cosa fare nelle prime ore l'abbiamo scritto in sito hackerato: le prime 24 ore.

Non cambiare l'asterisco in ! per stare tranquillo: ! blocca l'account anche per le chiavi.

Il numero di versione inganna

Sui rami stabili Alpine non è passata alla 10.6p2: ha portato la correzione dentro la versione che aveva. Su Alpine 3.24 il pacchetto corretto è il 10.3_p1-r2, e ssh -V continua a scrivere OpenSSH_10.3p1. Si guarda la versione del pacchetto, con apk list --installed 'openssh*', e la si confronta con la tabella dell'avviso.

Abbiamo letto anche lo script di controllo pubblicato dal ricercatore. Gli altri controlli sono fatti bene: musl, PAM, account con l'asterisco, hash da cui prendere il sale. Sulla versione però considera corretto solo un sshd che si dichiara 10.6p2 o successivo, quindi su un Alpine 3.24 aggiornato, con le password accese e i due tipi di account, risponde «EXPOSED». È un falso allarme, e chi lo lancia di corsa finisce a cercare un aggiornamento che ha già installato.

L'embargo è durato un giorno

Kültekin racconta di aver compilato sshd in ogni combinazione, con e senza musl, con e senza PAM, e di avergli lanciato contro circa 17.600 accessi strani con sciami di agenti AI. Miller nella mail spiega la fretta così: hanno visto più volte agenti AI ritrovare un bug in poche ore, e un embargo lungo ormai aiuta soprattutto chi attacca. Fra l'annuncio e il primo tentativo visto da Previdian è passata mezza giornata, meno delle 24 ore che il Cyber Resilience Act darà a chi produce software per segnalare una falla sfruttata.

Hai un server Alpine raggiungibile da internet e non sai dire in un minuto se accetta le password? Scrivici e lo guardiamo insieme.