Una password compresa tra 257 e 1.024 byte può aprire via SSH un account che non dovrebbe accettare password. Il bug, battezzato sshole e registrato come CVE-2026-123158, interessa alcune configurazioni di OpenSSH su Linux che usano la libreria musl senza PAM. OpenSSH e Alpine Linux hanno pubblicato le correzioni il 5 novembre.
Non basta avere Linux o Alpine per essere esposti: devono verificarsi diversi requisiti, tra cui l’accettazione dell’autenticazione tramite password da parte del server e la presenza di account con determinati campi e hash. Tuttavia, può bastare una sola connessione per sfruttare la vulnerabilità. Previdian ha segnalato otto tentativi provenienti dallo stesso indirizzo IP e ha confermato che uno ha ottenuto l’accesso come amministratore a un server-esca.
Un confronto tra stringhe che porta all’accesso
SSH consente di amministrare i dispositivi attraverso la rete; OpenSSH è un’implementazione diffusa del protocollo e sshd è il suo server. In Linux, /etc/shadow contiene i dati usati per verificare le password. In alcuni account configurati per autenticarsi solo con chiavi, il campo della password contiene un asterisco: *. Questo simbolo dovrebbe impedire l’accesso tramite una password ordinaria, non autorizzarlo.
Il bug si verifica quando sshd tenta di verificare una password per un account il cui campo non contiene un hash utilizzabile. Nelle compilazioni senza PAM, OpenSSH usa la funzione crypt() della libreria di sistema per elaborare il tentativo e confrontarlo con il valore memorizzato. Se il campo dell’account non contiene un salt che consenta di effettuare questa verifica, il server prende in prestito il salt di un altro account.
In musl, crypt() restituisce * come indicatore di errore se la password supera i 256 byte. Il risultato coincide con il carattere memorizzato negli account senza password. Il confronto finisce per considerare uguali due valori che non rappresentano una password valida e l’autenticazione viene accettata. La finestra sfruttabile descritta da Alpine e OpenSSH va da 257 a 1.024 byte.
Alpine riassume così i requisiti pratici: l’attaccante deve conoscere il nome di un account con * nel campo della password e il dispositivo deve avere almeno un altro account locale con un hash che inizi con $5$ o $6$, corrispondenti a SHA-256 e SHA-512. È sufficiente un account con password perché gli account senza password possano essere esposti, purché siano soddisfatte anche le altre condizioni.
“An attacker who can reach your SSH port can log in without knowing any password. It takes one connection, works every time, and needs no retries.”
— Team di Alpine Linux
Alpine riunisce i requisiti, ma non è l’unico sistema da controllare
Il caso confermato da Alpine riguarda i dispositivi che eseguono il pacchetto openssh-server, compilato senza PAM, oppure openssh-server-pam con UsePAM no. L’autenticazione tramite password deve essere abilitata; Alpine indica che OpenSSH la attiva per impostazione predefinita, a meno che l’amministratore non modifichi la configurazione. Deve inoltre esistere un account il cui campo sia * e un altro account locale con un hash $5$ o $6$.
Tra gli account che possono avere l’asterisco ci sono root, gli utenti creati per autenticarsi esclusivamente con chiavi e gli account provenienti da servizi di directory tramite musl-nscd, come nslcd, winbind o sssd. In Alpine, l’account root è impostato come root:* nell’immagine di base da circa la versione 3.16. Tuttavia, la configurazione predefinita PermitRootLogin prohibit-password lo protegge dall’accesso diretto tramite password. Questa barriera non elimina il rischio se un altro account che può effettuare l’accesso ottiene i privilegi di root, per esempio tramite doas.
Alpine considera interessate tutte le versioni verificate: dalla 3.21 alla 3.24 e edge, oltre ai rami più vecchi dalla 3.16 alla 3.20, che non ricevono più aggiornamenti regolari. La vulnerabilità non è necessariamente limitata a questa distribuzione: altre compilazioni di OpenSSH basate su musl e senza PAM possono presentare le stesse condizioni. Help Net Security cita OpenWrt, Buildroot e Yocto tra i sistemi da controllare.
Secondo l’avviso di Alpine, non sono interessati i dispositivi con PasswordAuthentication no, quelli che usano PAM con UsePAM yes, quelli privi di hash delle password nel formato $ e gli account bloccati il cui campo inizia con !. Non sono interessati neppure i container Docker o altri container che non eseguono sshd, né le immagini cloud configurate tramite cloud-init, che impostano PasswordAuthentication no.
Red Hat ha dichiarato che i suoi prodotti non sono interessati: le sue compilazioni di OpenSSH si collegano a glibc e usano PAM per impostazione predefinita. Help Net Security indica inoltre come estranei allo scenario Debian, Ubuntu e Fedora, che usano glibc, così come le configurazioni che passano da PAM, Dropbear e OpenBSD. La condizione decisiva non è semplicemente la distribuzione, ma la combinazione di libreria, autenticazione e account.
Le immagini tiny-cloud possono passare da sicure a vulnerabili
Alpine ha individuato un rischio specifico nelle sue immagini ufficiali tiny-cloud, distribuite come artefatti qcow2, VHD e AMI. Le immagini delle versioni dalla 3.18.11 alla 3.24.3 includono un utente alpine con il campo della password impostato su * e accesso a doas senza password. Sono sicure al primo avvio, ma possono diventare sfruttabili non appena compare sulla macchina un hash $6$.
Può accadere, per esempio, se un amministratore imposta una password dalla console o se i dati utente aggiungono un account con hashed_passwd. Se l’attaccante accede come alpine, può usare doas per diventare root. Le immagini create con Alpine 3.21.10, 3.22.8, 3.23.8, 3.24.4 e versioni successive includono già il pacchetto corretto; per le immagini delle versioni precedenti è necessario aggiornare OpenSSH o disabilitare l’autenticazione tramite password in ogni istanza ancora in funzione.
Alpine precisa che gli utenti delle immagini cloud configurate da cloud-init non rientrano nello scenario descritto, perché questo strumento imposta PasswordAuthentication no. La differenza tra un’immagine appena avviata e una macchina modificata in seguito è importante: aggiungere una password o un account può soddisfare una delle condizioni che prima mancavano.
Un bug nato da decisioni separate
Il ricercatore Özgün Kültekin, di Wakefield, ha segnalato il problema. La spiegazione tecnica collega modifiche introdotte in momenti diversi. Nel 2012, musl ha limitato la lunghezza delle password elaborate per evitare attacchi di denial of service; in caso di input troppo lungo, crypt() restituisce l’asterisco di errore. Nel 2016, OpenSSH ha modificato la verifica degli account senza un hash utilizzabile per rendere più difficile a un attaccante dedurre quali nomi utente esistessero misurando i tempi di risposta.
Anche Alpine ha modificato nel 2022 la configurazione del proprio account amministratore per consentire l’accesso tramite chiavi SSH. Ogni modifica rispondeva a un problema o a un’esigenza diversa. L’interazione tra la gestione degli errori di musl e il meccanismo di verifica di OpenSSH ha fatto sì che il simbolo usato per segnalare un errore coincidesse con il campo degli account senza password.
Help Net Security aggiunge che Kültekin ha provato diverse compilazioni di sshd ed eseguito circa 17.600 tentativi di accesso insoliti. Secondo la testata, solo la compilazione con musl e senza PAM ha consentito accessi che avrebbero dovuto essere rifiutati. Kültekin ha dichiarato di aver utilizzato agenti IA per il lavoro, anche se le informazioni disponibili non specificano quale parte dei test sia stata eseguita da ciascuno.
Nelle note della versione 10.6p2, OpenSSH ha dichiarato di ritenere che la causa principale sia esterna a sshd, ma che il problema possa essere sfruttato tramite il server e prevenuto al suo interno. L’aggiornamento include una correzione in OpenSSH. Alpine, da parte sua, ha distribuito pacchetti corretti per i propri rami.
Previdian ha confermato un accesso; i primi resoconti erano discordanti
La vulnerabilità è stata resa pubblica il 5 novembre insieme alle correzioni. Il 6 novembre, Help Net Security ha riferito che Previdian aveva rilevato attività nei propri sensori: otto tentativi, tutti provenienti da un unico indirizzo IP giapponese e catturati da un sensore. L’azienda ha confermato che uno di essi è riuscito a ottenere l’accesso come root in un honeypot con Alpine Linux e OpenSSH reali.
Il fondatore di Previdian, Ryan Dewhurst, ha dichiarato a Help Net Security che il primo tentativo rilevato è arrivato meno di nove ore dopo la pubblicazione della CVE. Secondo la sua descrizione, l’indirizzo di origine 89.116.89[.]18 ha inviato password eccessivamente lunghe ed eseguito comandi di ricognizione come id, uname e hostname in sessioni SSH non interattive. Previdian ha aggiunto il bug al proprio elenco di vulnerabilità sfruttate. In quel momento CISA non lo aveva inserito nel catalogo KEV.
L’articolo di SecurityWeek pubblicato lo stesso giorno descriveva una situazione precedente: affermava che non erano ancora stati segnalati casi di sfruttamento e prevedeva che le scansioni potessero iniziare nel giro di poche ore. Fredrik Almroth, cofondatore di Detectify e ricercatore capo della sicurezza, ha stimato che Shodan mostrasse circa 22 milioni di sistemi con SSH aperto sulla porta 22, avvertendo però che il numero reale era superiore e che solo una parte avrebbe eseguito Alpine. Jake Knott, responsabile dell’intelligence sulle minacce di WatchTowr, si aspettava tentativi di forza bruta prima del fine settimana. Il successivo rapporto di Help Net Security ha confermato i tentativi e l’accesso al sistema-esca.
Le note di OpenSSH spiegano perché la pubblicazione sia avvenuta rapidamente. Il team ha dichiarato di aver ricevuto numerose segnalazioni di bug di sicurezza, diversi dei quali individuati da modelli di IA o con il loro aiuto, e di aver osservato casi in cui un altro ricercatore scopre in modo indipendente un bug identificato per primo da strumenti di IA. Per questo motivo, ha annunciato che per il momento pubblicherà versioni più frequentemente, così da distribuire le correzioni prima, invece di raggrupparle fino alla successiva release prevista.
Aggiornare non basta se il vecchio processo è ancora in esecuzione
OpenSSH ha pubblicato la versione 10.6p2 il 5 novembre 2026. La correzione impedisce il bypass in sshd; le note includono anche altre modifiche, tra cui l’abilitazione dell’algoritmo ibrido di firma post-quantistica ssh-mldsa44-ed25519 come algoritmo consentito per le firme CA e la correzione di un picco di utilizzo della CPU inferiore a un secondo quando si usava ChannelTimeout.
Alpine ha pubblicato pacchetti corretti per i rami dalla 3.16 a edge. Le versioni indicate nel suo avviso sono: edge, 10.6_p2-r0; 3.24, 10.3_p1-r2; 3.23, 10.2_p1-r1; 3.22, 10.0_p1-r11; 3.21, 9.9_p2-r1; 3.20, 9.7_p1-r6; 3.19, 9.6_p1-r3; 3.18, 9.3_p2-r4; 3.17, 9.1_p1-r7; e 3.16, 9.0_p1-r6. I rami 3.21 e precedenti includono versioni che non ricevono più supporto regolare; Alpine ha comunque pubblicato pacchetti corretti fino alla 3.16. La versione 3.21 ha raggiunto la fine del supporto il 1° novembre 2026.
Il passaggio operativo sottolineato da Alpine è riavviare sshd dopo l’aggiornamento: installare il pacchetto non sostituisce il processo già in esecuzione. Se non è possibile applicare la patch, l’avviso consiglia di disabilitare PasswordAuthentication e riavviare il servizio. Prima di farlo, occorre verificare che l’accesso tramite chiave funzioni e mantenere aperta la sessione corrente finché non si è provata una nuova connessione, per evitare di perdere l’accesso amministrativo.
Per cercare indizi di intrusione, Alpine consiglia di controllare /var/log/messages alla ricerca di righe di sshd contenenti “Accepted password for” per account senza password, come alpine, root o utenti con accesso esclusivo tramite chiave. Consiglia inoltre di verificare l’uso di doas, gli account creati di recente, i file e le chiavi autorizzate sui dispositivi esposti. Se non è possibile escludere un accesso, Alpine indica di considerare il sistema compromesso.
Help Net Security ha inoltre riferito che su GitHub circolavano proof of concept, ma Previdian ha avvertito che non erano verificate e potevano contenere malware. Per gli amministratori, l’intervento immediato indicato da Alpine e OpenSSH resta concreto: aggiornare il pacchetto e riavviare il demone oppure disabilitare l’accesso tramite password e riavviarlo in attesa dell’aggiornamento.
Fonti: Xataka, Alpine Linux, OpenSSH, Red Hat, Help Net Security, SecurityWeek
