Una vulnerabilità critica di OpenSSH, ribattezzata come *sshole, potrebbe consentire a un attaccante remoto di aggirare l’autenticazione tramite password sui server Alpine Linux interessati e ottenere accesso non autorizzato.
La vulnerabilità interessa specifiche configurazioni di sistemi Linux che utilizzano la libreria musl libc, tra cui Alpine Linux. Il 5 novembre 2026 è stata rilasciata una versione correttiva di OpenSSH per risolvere il problema.
Indice dei contenuti:
Quali sistemi Linux sono vulnerabili?
La vulnerabilità non interessa indistintamente tutte le installazioni OpenSSH, ma riguarda sistemi Linux basati su musl libc, come Alpine Linux, una distribuzione ampiamente utilizzata negli ambienti cloud, nei container e nelle infrastrutture che richiedono un sistema operativo essenziale.
Perché il bypass dell’autenticazione sia sfruttabile, devono verificarsi contemporaneamente alcune condizioni:
- Il server utilizza una versione vulnerabile di OpenSSH.
- Il sistema è basato su musl libc e non utilizza PAM per l’autenticazione SSH.
- L’autenticazione tramite password è abilitata.
- È presente almeno un account con il carattere
*nel campo della password. - Esiste almeno un altro account locale con un hash di password compatibile con le condizioni necessarie allo sfruttamento.
Le versioni potenzialmente interessate, qualora presentino le condizioni sopra descritte, sono quelle dalla 3.21 alla 3.24 e il ramo edge, oltre alle versioni precedenti dalla 3.16 alla 3.20 che non ricevono più aggiornamenti regolari.
Le distro che utilizzano glibc, come Ubuntu, Debian e Fedora nelle configurazioni standard, non sono interessate da questo specifico problema.
Quali sono i rischi per i server?
Il principale rischio associato alla vulnerabilità *sshole è l’accesso non autorizzato a un sistema attraverso il servizio SSH. Un attaccante che riesca a sfruttare la falla potrebbe ottenere una sessione sul server con i privilegi dell’account compromesso.
Le conseguenze dipendono dai permessi associati all’utente e dalla configurazione dell’infrastruttura, ma possono includere:
- Accesso non autorizzato a file e informazioni riservate.
- Modifica o cancellazione di dati e configurazioni.
- Installazione di software malevolo o creazione di accessi persistenti.
- Compromissione di applicazioni e servizi ospitati.
- Possibile escalation dei privilegi fino all’accesso amministrativo.
Un caso particolarmente delicato riguarda alcune immagini cloud ufficiali di Alpine Linux, nelle quali l’utente predefinito alpine può eseguire comandi amministrativi attraverso doas senza inserire una password.
Se sono presenti anche le altre condizioni necessarie, un attaccante potrebbe quindi ottenere privilegi elevati e compromettere il sistema.
Quali azioni di mitigazione mettere in atto?
Per correggere il problema, il progetto OpenSSH ha rilasciato il 5 novembre 2026 la versione 10.6p2, che introduce una protezione contro il bypass dell’autenticazione. Anche Alpine Linux ha pubblicato aggiornamenti correttivi per le versioni interessate.
1. Aggiorna OpenSSH
La prima raccomandazione è verificare la versione di OpenSSH installata e applicare tempestivamente gli aggiornamenti di sicurezza disponibili attraverso i repository ufficiali della propria distribuzione.
Non è sempre necessario installare direttamente OpenSSH 10.6p2: alcune distribuzioni hanno integrato la correzione nelle versioni precedenti attraverso patch dedicate.
Dopo l’aggiornamento, è importante riavviare il servizio SSH affinché venga effettivamente utilizzata la versione corretta.
2. Se non riesci ad aggiornare, disabilita l’autenticazione SSH tramite password
Se l’accesso al server avviene attraverso chiavi SSH, è consigliabile disabilitare l’autenticazione tramite password. La direttiva da utilizzare nella configurazione del server SSH è:
PasswordAuthentication no
Questa impostazione impedisce l’utilizzo delle password per l’accesso SSH e costituisce una misura di mitigazione efficace anche quando non è possibile applicare immediatamente la patch.
Prima di modificare la configurazione, è comunque necessario verificare che sia disponibile un metodo di accesso alternativo funzionante, per evitare di perdere l’accesso al server.
3. Verifica i log
È importante analizzare i log di autenticazione SSH, disponibili ad esempio nel file /var/log/messages, per individuare eventuali accessi sospetti. In particolare, occorre verificare la presenza di messaggi Accepted password for relativi ad account che non dovrebbero consentire l’autenticazione tramite password, come alpine, root o utenti configurati per l’accesso esclusivamente tramite chiavi SSH.
È inoltre consigliabile controllare l’utilizzo di doas e verificare la presenza di nuovi utenti, file o chiavi SSH autorizzate che potrebbero indicare un accesso non autorizzato. Se non è possibile escludere una compromissione, il server deve essere considerato potenzialmente compromesso e sottoposto alle opportune verifiche di sicurezza.
Per qualsiasi richiesta di supporto o chiarimento, il Team di Shellrent è disponibile.
