Per favore, aggiungi TurboLab.it alle eccezioni del tuo Ad Blocker. Siamo un progetto no-profit, e la pubblicità è indispensabile per pagare le spese.
In alternativa, puoi sostenerci con una donazione.
Rispetteremo ogni tua scelta, e potrai sempre utilizzare il sito senza limitazioni.
Un account SSH configurato per rifiutare l'accesso tramite password può essere violato inviando... una password. Basta che sia abbastanza lunga. È questa, in sostanza, la vulnerabilità ribattezzata "*sshole" (CVE-2026-123158) che colpisce OpenSSH sui sistemi Linux basati su musl, a partire da Alpine Linux. La falla aggira il meccanismo che blocca gli account impedendone il login via password, trasformando un server che l'amministratore credeva protetto in una porta spalancata. Considerando quanto Alpine sia diffuso come base per le immagini Docker, la superficie d'attacco potenziale è enorme.
La correzione è arrivata il 5 novembre 2026 con il rilascio di OpenSSH 10.6p2. Lo stesso giorno Alpine Linux ha pubblicato i pacchetti aggiornati e il proprio advisory, retroportando la patch a tutti i rami, dalla 3.16 fino a edge.
MITRE assegna alla vulnerabilità un punteggio di 8.1 (High) su scala CVSS 3.1. A scoprirla è stato Özgün Kültekin di Wakefield, che le ha dato il soprannome e l'ha documentata sul sito sshhole.com.
Il cuore del problema sta in come interagiscono tre componenti indipendenti. Gli account bloccati (utenti che accedono solo con chiave, utenti di sistema, utenti gestiti via LDAP) hanno un asterisco * nel campo password del file /etc/shadow. Quando sshd è compilato senza PAM, calcola l'hash della password inviata tramite la funzione crypt() della libreria C e lo confronta con il valore memorizzato.
Qui scatta la trappola. L'implementazione di crypt() in musl limita le password SHA-512 a 256 byte. Superata quella soglia la funzione fallisce e restituisce la stringa di un solo carattere *, che combacia esattamente con il * memorizzato per un account bloccato. Il login va a buon fine al primo tentativo, senza alcun brute force. Nei test pubblicati, l'intervallo di lunghezza efficace va da 257 a 1.024 caratteri.
L'origine è antica. Nel 1980 Bill Joy inserì l'asterisco in /etc/passwd per l'account del demone in 3BSD. Nell'agosto 2012 musl modificò crypt() perché restituisse * invece di NULL in caso di errore, e venti giorni dopo introdusse il limite di 256 byte per SHA-512, pensato proprio per evitare un denial of service con password gigantesche. Perché la falla scatti serve però un altro ingrediente: dal 2016 (correzione di CVE-2016-6210, contro l'enumerazione degli utenti) sshd prende in prestito il salt da un altro account. Senza un vero hash $5$ o $6$ su qualche account, il percorso difettoso non si attiva mai.
Le condizioni devono valere tutte insieme:
sshd in esecuzione senza PAM (configurazione predefinita del pacchetto openssh-server di Alpine)PasswordAuthentication abilitato (il default di OpenSSH)$5$ o $6$.Oltre ad Alpine, rientrano nel perimetro i sistemi musl come OpenWrt, Buildroot e Yocto dove PAM è disattivato.
Sono immuni i sistemi basati su glibc (Debian, Ubuntu, Fedora) e quelli che effettuano il login tramite PAM.
L'utente root è protetto dall'impostazione predefinita PermitRootLogin prohibit-password.
Attenzione però alle immagini cloud ufficiali di Alpine (dalla 3.18.11 alla 3.24.3): includono un utente alpine che può eseguire doas come root senza password, trasformando l'accesso in un controllo completo della macchina.
Sul fronte container, Cycode ha analizzato immagini pubbliche di Docker Hub che espongono un server SSH. Diverse immagini molto usate disabilitano il login con password, come Gitea, Gogs, l'agente SSH di Jenkins e linuxserver openssh-server (a meno di impostare PASSWORD_ACCESS=true). Secondo Cycode, un piccolo numero di immagini risultava invece vulnerabile nella configurazione documentata, ma non indica quali né quante. Le immagini basate su release di Alpine precedenti alla 3.16 erano sfruttabili nei test e non ricevono alcun pacchetto corretto.
Il primo passo è verificare l'esposizione. Da root, esegui:
sshd -T | grep -i -E 'passwordauthentication|usepam'
Se l'autenticazione via password è disattivata o PAM è attivo, il sistema non è vulnerabile. Per aggiornare su Alpine basta apk upgrade -U -a seguito da rc-service sshd restart; le immagini con un pacchetto openssh più vecchio vanno ricostruite e ridistribuite. Come soluzione tampone, imposta PasswordAuthentication no e riavvia sshd (prima verifica che il login con chiave funzioni). Sulle release di Alpine precedenti alla 3.16, che non ricevono la patch, questo workaround è l'unica difesa disponibile.
Per capire se qualcuno ha già sfruttato la falla, cerca in /var/log/messages la stringa Accepted password associata a un account che non ha password: se la trovi, considera il sistema compromesso. Non risultano segnalazioni di sfruttamento attivo, ma la banalità dell'attacco non lascia spazio a rinvii.
C'è una lezione più ampia nella tempistica. La correzione è arrivata entro un giorno dalla segnalazione, e i manutentori di OpenSSH hanno spiegato di aver abbandonato i lunghi embargo perché gli strumenti di AI riscoprono i bug segnalati, a volte nel giro di ore. Il consiglio di Cycode è diretto: pianificare l'aggiornamento di OpenSSH entro poche ore da ogni rilascio. In un mondo dove una patch pubblicata è anche una mappa per l'attaccante, aspettare il weekend non è più un'opzione.
Fonti: techplanet.today, daily.dev
Nessuno ha ancora commentato.
