Lo scenario da incubo perfetto per un server Linux è quando tutto ciò che serve a un attaccante è raggiungere la porta Secure Shell (SSH) del server, entrare bellamente e prendere il controllo. È quello che è successo ad Alpine Linux, la popolare distribuzione Linux leggera per server. Per aggiungere beffa al danno, ciò è avvenuto solo pochi giorni dopo che Alpine Linux aveva schivato un proiettile grande quanto una falla di sicurezza alla sua implementazione di GitLab.

Come ha spiegato l'ingegnere della sicurezza Gregory Bryant nel suo post su LinkedIn: "La maggior parte dei bypass di autenticazione deriva da catene logiche complesse, ma la vulnerabilità di OpenSSH di Alpine Linux di ieri (CVE-2026-123158) si riduce a un singolo carattere: *."

Se esegui Alpine Linux (o un'altra distro basata su musl) con il pacchetto openssh-server predefinito (senza Pluggable Authentication Modules, o PAM) e PasswordAuthentication abilitato, un attaccante può accedere ad account con password disabilitata, o solo con chiave, semplicemente inviando una password lunga tra 257 e 1024 byte.

Alpine Linux non è l'unico sistema operativo che utilizza musl, una versione leggera della libreria C standard (libc). Altri sistemi operativi che usano musl e sono potenzialmente vulnerabili includono Adélie Linux; Void Linux; Sabotage Linux; OpenWrt, una variante di Android; e il Progetto Yocto, utilizzato per costruire distribuzioni Linux embedded.

Anche Wind River, che produce la distro Linux embedded commerciale Wind River Linux, sta esaminando il problema. Un rappresentante dell'azienda mi ha detto: "Wind River prende sul serio la sicurezza. Stiamo attivamente riesaminando la vulnerabilità segnalata e valutandone il potenziale impatto. Adotteremo le azioni appropriate secondo necessità."

Dietro le quinte, quando OpenSSH viene compilato senza PAM, verifica le password eseguendo l'hash del tentativo di password usando la funzione crypt() della libreria C. Poi confronta il risultato con il campo password memorizzato dell'account. Fin qui tutto bene.

Ma quando una chiave è più lunga di 256 byte, la funzione crypt() di musl restituisce la stringa * come indicatore di errore. Questo è anche ciò che il campo password contiene per qualsiasi account senza password, come un account solo con chiave. Quindi l'"hash" corrisponde e l'accesso riesce, e l'attaccante entra.

Per sfruttarla, un attaccante ha solo bisogno del nome di un tale account. Ha anche bisogno di almeno un altro account sulla macchina con un hash della password a 5 o 6, e poi di inviare una password da 257 a 1.024 byte. Secondo Alpine, un utente con una password è sufficiente per rendere accessibili tutti gli account senza password.

Nei sistemi Linux che usano crypt() di glibc, cioè quasi tutti, lo stesso tentativo restituirebbe NULL in caso di errore, che sshd rifiuta già, quindi Debian, Ubuntu, Fedora, ecc., non sono interessati.

Secondo *sshole, il gruppo che ha scoperto il problema, questo è un effetto collaterale che si nasconde dal 2016.

Alpine ha dichiarato che ogni versione controllata è interessata: dalla 3.21 alla 3.24, edge, e i rami più vecchi dalla 3.16 alla 3.20. L'esposizione richiede quanto segue:

Root non è direttamente esposto nella maggior parte dei casi. È stato distribuito come root:* nell'immagine base a partire circa da Alpine 3.16, ma l'impostazione predefinita di OpenSSH PermitRootLogin prohibit-password lo blocca. Un altro account che può diventare root, ad esempio tramite doas, offre comunque a un attaccante una via per ottenere root.

Alpine ha indicato le sue immagini ufficiali tiny-cloud, versioni dalla 3.18.11 alla 3.24.3, come particolarmente vulnerabili. Queste vengono fornite con un utente alpine con un campo password * e doas senza password. Sono sicure al primo avvio ma diventano sfruttabili una volta che qualsiasi hash a 6 esiste sulla macchina. Ciò può accadere quando un amministratore imposta una password di console o quando i dati utente aggiungono un utente con una password hashata, il che significa, essenzialmente, tutte.

Alpine ha rilasciato 3.21.10, 3.22.8, 3.23.8 e 3.24.4 giovedì, con la correzione di OpenSSH tra le modifiche di sicurezza. Ha anche pubblicato pacchetti corretti per ogni versione fino alla 3.16. Alpine 3.21 ha raggiunto la fine del supporto il 1° novembre.

La versione appena rilasciata di OpenSSH 10.6p2 evita il problema in sshd. I rami stabili di Alpine contengono una patch per lo stesso problema. Dovresti eseguire apk upgrade -U -a e poi riavviare th