Ing. Calogero Bono
Il 5 novembre 2026 è uscito OpenSSH 10.6p2, che corregge un bug battezzato «*sshole». Riguarda i server SSH su Linux che usano la libreria musl, come Alpine Linux, con la PAM disattivata. Chi arriva alla porta SSH può entrare in un account senza password inviando una password molto lunga. Conta perché basta una connessione e perché le immagini cloud ufficiali di Alpine possono dare accesso come root.
Qualche termine, prima di entrare nei fatti. musl è una libreria C alternativa a glibc, usata da Alpine, OpenWrt, Buildroot e Yocto. crypt() è la funzione che trasforma una password nel suo hash. PAM è il sistema modulare di autenticazione di Linux. /etc/shadow è il file che conserva gli hash delle password. doas è lo strumento, simile a sudo, per ottenere privilegi di root.
Come funziona il bug *sshole?
Un account Linux senza password ha un asterisco al posto dell'hash in /etc/shadow. Nessuna password dovrebbe aprirlo. Secondo BleepingComputer, una modifica a OpenSSH del 2016, nata per correggere la CVE-2016-6210 sull'enumerazione degli utenti, fa calcolare l'hash anche per questi account.
Qui entra musl. Come spiega l'avviso di Alpine, la crypt() di musl restituisce * come segnale di errore se la chiave supera i 256 byte. Quell'asterisco coincide con quello salvato nell'account, e il confronto riesce. Il ricercatore Özgün Kültekin dice che il difetto esiste dal 2016.
Chi è davvero a rischio?
Servono più condizioni insieme. Secondo Alpine, il pacchetto openssh-server è compilato senza PAM, oppure si usa openssh-server-pam con UsePAM no. PasswordAuthentication deve essere attivo, come da impostazione predefinita. Serve un account con * e almeno un altro con hash $5$ o $6$. Basta un solo utente con password per rendere raggiungibili tutti gli altri.
Alpine ha verificato le versioni dalla 3.21 alla 3.24 e edge, più le vecchie 3.16-3.20. Non sono toccati container senza sshd, sistemi con PasswordAuthentication no e sistemi con PAM attiva. Debian, Ubuntu e Fedora, che usano glibc, non sono vulnerabili, scrive BleepingComputer.
Perché le immagini cloud di Alpine preoccupano?
Le immagini ufficiali tiny-cloud, dalla 3.18.11 alla 3.24.3, hanno un utente alpine con password * e doas senza password. Alpine precisa che sono sicure al primo avvio. Diventano sfruttabili quando compare un hash $6$, per esempio se un amministratore imposta una password di console o se user-data aggiunge un utente con hashed_passwd.
A quel punto l'attaccante ottiene una shell come alpine e con doas diventa root. Le immagini configurate con cloud-init, che scrive PasswordAuthentication no, non sono colpite. Per root, il valore predefinito PermitRootLogin prohibit-password lo protegge solo in modo diretto.
Come si corregge e come si controlla un attacco?
La correzione è in OpenSSH 10.6p2. Su Alpine si usa apk upgrade -U -a, poi si riavvia sshd, perché l'aggiornamento non sostituisce il demone già in esecuzione. Alpine ha pubblicato pacchetti corretti fino alla 3.16, anche per le release non più supportate.
Se non puoi aggiornare, imposta PasswordAuthentication no e riavvia sshd, dopo aver verificato che l'accesso con chiave funzioni. Per cercare tracce, controlla in /var/log/messages le righe «Accepted password» per account senza password. Alpine aggiunge che, se non puoi escludere un accesso, la macchina va considerata compromessa. Per i permessi sugli account vale anche la guida sui permessi Linux.
Limiti da conoscere
Alpine segnala che al momento della pubblicazione non era stato assegnato alcun CVE. OpenSSH scrive che la causa va cercata fuori da sshd, ma è sfruttabile tramite sshd e lì viene evitata. Non ci sono dati su attacchi reali in corso. Le affermazioni sui 17.600 test con agenti IA vengono dal ricercatore, riportate da BleepingComputer, e non sono verificate in modo indipendente.
Cosa cambia per chi lavora con il digitale
Se gestisci server Alpine, router OpenWrt o sistemi embedded con Yocto e Buildroot, controlla se sshd consente password e se ci sono account con *. Molti usano Alpine in container senza sshd e non sono toccati. Chi tiene macchine cloud con le immagini tiny-cloud deve verificare ogni istanza già in esecuzione. Un server gestito con aggiornamenti regolari riduce questo tipo di rischio, ne parliamo nella pagina su hosting e server gestiti. Conviene anche tenere d'occhio il caso collegato degli exploit generati da IA, di cui abbiamo scritto in questo articolo.
Il nostro parere
Il caso mostra quanto sia fragile il confine tra componenti che si fidano l'una dell'altra. OpenSSH ha aggiunto una difesa legittima nel 2016, musl ha scelto un valore di errore comune, e insieme hanno aperto una porta per dieci anni. Colpisce anche che il bug sia stato trovato con agenti IA. OpenSSH stessa avverte che bug trovati con l'IA vengono spesso riscoperti da altri, quindi aspettare è un rischio. Il rimedio più solido resta lo stesso da sempre, chiavi al posto delle password.
Domande frequenti
Debian e Ubuntu sono vulnerabili a *sshole?
No. Usano glibc e non la libreria musl. BleepingComputer conferma che i sistemi con autenticazione PAM non sono vulnerabili, ma Alpine precisa che openssh-server-pam con UsePAM no lo è, mentre con UsePAM yes no.
Basta aggiornare il pacchetto openssh?
No, serve anche riavviare sshd. Alpine precisa che l'aggiornamento non sostituisce il demone già in esecuzione, quindi la versione vulnerabile resterebbe attiva.
Posso proteggermi senza aggiornare?
Sì, in via temporanea. Imposta PasswordAuthentication no nella configurazione di sshd e riavvia il servizio. Prima verifica che l'accesso con chiave funzioni.
Anche root è esposto?
Solo in certi casi. Con PermitRootLogin prohibit-password, il valore predefinito, root non è raggiungibile direttamente. Lo diventa se è attivo PermitRootLogin yes o se un altro utente può diventare root, per esempio con doas.
C'è un CVE per questo bug?
Non ancora, secondo Alpine. L'avviso dice che al momento della scrittura nessun identificatore era stato assegnato. Il riferimento sono le note di OpenSSH 10.6p2.
Cosa seguire dopo OpenSSH 10.6p2
OpenSSH ha annunciato rilasci più frequenti per portare le correzioni agli utenti più in fretta. Il bug lascia aperte alcune questioni da seguire.
- Controlla se verrà assegnato un CVE e se i tuoi strumenti di scansione lo riconosceranno.
- Verifica quando i produttori di firmware basati su OpenWrt, Buildroot e Yocto pubblicheranno aggiornamenti.
- Prepara una routine per installare i rilasci minori di OpenSSH senza aspettare le versioni pianificate.
