{"id":184154,"date":"2026-11-05T23:41:11","date_gmt":"2026-11-05T21:41:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/sshole-uyazvimost-pozvolyayushhaya-podklyuchitsya-po-ssh-bez-parolya-v-sistemah-s-musl"},"modified":"2026-11-05T23:41:15","modified_gmt":"2026-11-05T21:41:15","slug":"sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","title":{"rendered":"SSHole \u2014 una vulnerabilit\u00e0 che consente di connettersi via SSH senza password in sistemi con Musl","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli sviluppatori di OpenSSH hanno pubblicato un aggiornamento urgente per OpenSSH 10.6p2, che include una protezione contro una vulnerabilit\u00e0 critica (CVE non assegnato), soprannominata 'SSHole', che consente di bypassare l'autenticazione. Nei sistemi con la libreria Musl, la vulnerabilit\u00e0 consente di connettersi a un utente per il quale non \u00e8 prevista una password, inserendo qualsiasi password che contenga pi\u00f9 di 256 caratteri. Il problema colpisce le distribuzioni Linux che utilizzano la libreria standard musl, ma non PAM (Pluggable Authentication Modules), come OpenWRT, Alpine, Buildroot e Yocto. \u00c8 particolarmente preoccupante che spesso l'accesso con password sia bloccato per l'utente root, il che consente a chiunque di connettersi da remoto con diritti di amministratore.<\/p>\n
L'errore che porta alla vulnerabilit\u00e0 non \u00e8 nel codice di OpenSSH, ma viene sfruttato tramite sshd. Data la gravit\u00e0 del problema, nella versione OpenSSH 10.6p2 \u00e8 stata proposta una soluzione temporanea per bloccare la vulnerabilit\u00e0. Ai proprietari dei sistemi vulnerabili si consiglia di non aspettare l'arrivo di aggiornamenti, ma di disabilitare immediatamente l'autenticazione tramite password modificando il parametro 'PasswordAuthentication no' in \/etc\/ssh\/sshd_config o disabilitando completamente SSH. <\/p>\n
Il problema non si manifesta nei sistemi diversi da Linux e negli ambienti Linux basati su glibc, nonch\u00e9 nei sistemi che utilizzano PAM per l'autenticazione tramite password. La correzione \u00e8 gi\u00e0 disponibile in Alpine e OpenWRT.<\/p>\n
La vulnerabilit\u00e0 \u00e8 legata all'interazione scorretta tra OpenSSH e la funzione crypt() di musl. Per proteggere dall'individuazione dell'esistenza di utenti attraverso l'analisi delle differenze nei tempi di elaborazione delle richieste, dal 2016 OpenSSH utilizza una procedura standard per il controllo delle credenziali senza password: chiama la funzione 'crypt(password fornita, sale)' con il sale di un altro utente che ha un hash di password valido, quindi confronta l'hash restituito dalla funzione crypt con il valore presente nel campo contenente l'hash della password.<\/p>\n
Tuttavia, in musl, la funzione crypt() per gli hash SHA-512 restituisce il simbolo '*' se la lunghezza della password fornita supera i 256 byte (limite introdotto nel 2012 per proteggere da attacchi DoS, poich\u00e9 l'invio di valori di grandi dimensioni provoca un elevato carico sulla CPU). Lo stesso simbolo \u00e8 utilizzato nel campo contenente l'hash della password in '\/etc\/shadow' per indicare gli account per i quali l'autenticazione tramite password \u00e8 stata bloccata. <\/p>\n
Di conseguenza, un attaccante che ha la possibilit\u00e0 di connettersi a un server SSH pu\u00f2 accedere a qualsiasi account nel quale nel campo della password in \u00ab\/etc\/shadow\u00bb \u00e8 presente il simbolo \u00ab*\u00bb, inviando una stringa di lunghezza compresa tra 257 e 1024 byte. Il problema coinvolge molti dei container Docker esistenti, costruiti utilizzando Alpine Linux, cos\u00ec come le immagini Alpine di serie per i sistemi cloud AWS e Azure, in cui per l'utente root \u00e8 stato impostato il simbolo \u00ab*\u00bb invece dell'hash della password. <\/p>\n
\u00c8 interessante notare che inizialmente, nei container Docker ufficiali che utilizzano Alpine, dal 2015 era impostata una password vuota per root e, dopo la scoperta di questo, al posto dell'hash della password \u00e8 stato impostato il simbolo \u00ab!\u00bb . Tuttavia, la sua presenza bloccava l'accesso tramite chiavi SSH, quindi dal 2022 il simbolo per bloccare l'accesso tramite password \u00e8 stato sostituito con il simbolo \u00ab*\u00bb. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"