Una password troppo lunga basta per entrare in Alpine Linux: ecco cosa è successo

Se amministri server Alpine Linux, container Docker o macchine virtuali cloud, c'è una vulnerabilità che richiede attenzione immediata. Secondo Tom's Hardware, una combinazione di difetti in OpenSSH e nella libreria musl-libc permette a chiunque di accedere a sistemi vulnerabili semplicemente digitando una password di oltre 256 caratteri — il contenuto esatto non importa. Non è un'ipotesi teorica: OpenSSH ha già rilasciato la versione 10.6p2 il 5 novembre 2026 per bloccare il problema, e Alpine ha pubblicato patch per ogni versione dalla 3.16 in poi.

Chi

OpenSSH è il software di accesso remoto più diffuso su Internet, usato da praticamente ogni server Linux, dispositivo embedded e container. musl-libc è la libreria C su cui si basa Alpine Linux, una distribuzione leggera diventata lo standard de facto per i container Docker e Kubernetes in tutto il mondo. Alpine è presente in milioni di installazioni: container, server cloud, dispositivi embedded, ambienti di sviluppo.

Cosa è successo

La vulnerabilità sfrutta un'interazione tra due comportamenti distinti. Quando OpenSSH autentica un utente tramite password (senza usare il sistema PAM — Pluggable Authentication Module), verifica la password usando la funzione crypt() della libreria C. Per account senza password impostata, il campo password in /etc/shadow contiene un singolo asterisco *, che significa "nessuna password valida".

Quando OpenSSH deve verificare una password per un account senza password, prende il "salt" (il prefisso casuale usato per hashare) da un altro account che ha una password reale. Qui entra in gioco musl-libc: per i tipi di hash SHA-512 e SHA-256 (contrassegnati da $5$ e $6$), musl rifiuta password più lunghe di 256 byte e restituisce * come segnale di errore. Quel * viene poi confrontato con l'asterisco memorizzato per l'account senza password — e corrisponde. OpenSSH accetta il login.

L'attacco funziona con password tra 257 e 1.024 byte (il limite di OpenSSH). Non è necessario conoscere la password reale: qualsiasi stringa lunga abbastanza funziona. Un attaccante ha bisogno solo di:

• Accesso di rete al server SSH
• Il nome di un account senza password (come root, alpine o account creati solo per chiavi SSH)
• Almeno un altro account sulla macchina che abbia una password impostata

Alpine è particolarmente vulnerabile perché soddisfa tutti i requisiti per impostazione predefinita: l'autenticazione tramite password è abilitata, OpenSSH è compilato senza PAM, e account come root e alpine sono spesso privi di password nei container e nelle immagini cloud.

Perché è importante

Alpine Linux è diventato ubiquo negli ultimi anni. È la base di scelta per i container leggeri, le immagini Docker ufficiali, i sistemi embedded e i server cloud che richiedono footprint minimo. Una singola vulnerabilità in Alpine può potenzialmente esporre milioni di istanze.

Il problema non è limitato ad Alpine. La ricerca originale identifica OpenWrt, Buildroot e Yocto come altri sistemi basati su musl a rischio (anche se OpenWrt usa Dropbear per SSH per impostazione predefinita, non OpenSSH). Tuttavia, Alpine rimane il caso più critico per scala e configurazione predefinita.

Ciò che rende questa vulnerabilità particolarmente insidiosa è che non richiede accesso fisico, exploit complessi o credenziali valide. Un attaccante interno a una rete aziendale, un container compromesso in un cluster Kubernetes, o chiunque abbia accesso a una VPN aziendale può testare e sfruttare il difetto in pochi secondi. La ricerca di account vulnerabili è banale: basta provare account comuni come root o alpine con una password lunga.

Damien Miller del progetto OpenSSH ha consigliato a chiunque gestisca sistemi interessati di "impostare PasswordAuthentication=no o disabilitare SSH per questi sistemi IMMEDIATAMENTE". Nessun attacco noto è stato segnalato finora, ma il difetto è pubblico e la finestra di tempo per aggiornare i sistemi è critica.

Cosa aspettarsi

Alpine ha già distribuito patch per tutte le versioni supportate (3.21.10, 3.22.8, 3.23.8, 3.24.4 e oltre) e anche per versioni fuori supporto dalla 3.16 in poi. Chi esegue Alpine su server o container dovrebbe aggiornare immediatamente con apk upgrade -U -a seguito da rc-service sshd restart.

Per chi non può aggiornare subito, la mitigazione è disabilitare l'autenticazione tramite password nel file di configurazione di OpenSSH (/etc/ssh/sshd_config) impostando PasswordAuthentication no, assicurandosi prima che l'accesso tramite chiave SSH funzioni correttamente.

Alcuni indicatori da monitorare: i log di sistema (/var/log/messages) per voci di accesso riuscito tramite password per account che non dovrebbero avere password (come root o alpine). Se un'istanza è stata compromessa, gli amministratori dovrebbero verificare la cronologia di doas (il comando per elevare i privilegi in Alpine) e le chiavi SSH autorizzate aggiunte di recente.

I container Docker basati su Alpine dovrebbero essere ricostruiti con le immagini base aggiornate. I cluster Kubernetes dovrebbero aggiornare i pod Alpine e ricrearne le istanze. Le immagini cloud di Alpine create prima del 5 novembre 2026 rimangono vulnerabili finché non vengono aggiornate.

La responsabilità della vulnerabilità è condivisa: musl ha introdotto il comportamento di restituire * come segnale di errore nel 2012 per proteggere da attacchi denial-of-service, e OpenSSH ha iniziato a prendere il salt da altri account nel 2016. Nessuno dei due team ha previsto questa combinazione specifica. Tuttavia, entrambi hanno risposto rapidamente con patch.