6 novembre 2026

SSH e la password “troppo lunga”: anatomia di una vulnerabilità (e perché non è magia)

Un bypass di autenticazione legato a musl/crypt, configurazioni specifiche e una soglia critica intorno ai 256 byte.

Una vulnerabilità emersa nel 2026 ha riportato l’attenzione su un tema classico: cosa succede quando un input “esce dai binari” previsti. In alcuni scenari (tipicamente Alpine/musl e configurazioni SSH particolari), una password oltre una certa lunghezza può innescare un comportamento inatteso nel calcolo/verifica dell’hash, con esiti che arrivano fino al bypass di autenticazione. Vediamo condizioni, meccanismo, impatto reale e mitigazioni pratiche per chi mantiene immagini Docker, appliance embedded o stack basati su musl.

Quando si parla di vulnerabilità su SSH, l’istinto è pensare a crittografia rotta o a exploit “da film”. In realtà, alcune delle falle più pericolose nascono da una combinazione molto più banale: un input fuori scala, una libreria con un caso limite, e una catena di configurazioni che rende quel caso limite raggiungibile.

Negli ultimi mesi è stata discussa una vulnerabilità (CVE-2026-123158, punteggio 8.1) che, in condizioni specifiche, consente un bypass dell’autenticazione via password: inserendo una password molto lunga (tipicamente oltre i 256 byte) si può arrivare a un confronto “vero” anche senza conoscere la password corretta.

L’impatto non è universale: dipende da distribuzione, libc, impostazioni di sshd e dallo stato degli account locali. Proprio per questo è utile capirne la meccanica: aiuta sia a valutare il rischio, sia a impostare hardening sensato.

Il contesto: autenticazione SSH via password non è solo “confronta stringhe”

In un flusso standard di autenticazione via password, SSH riceve l’input dell’utente e lo verifica contro un hash memorizzato sul sistema (tipicamente in /etc/shadow). Questo implica:

  • lookup dell’account richiesto;
  • recupero dell’hash (e del salt) associato;
  • calcolo dell’hash della password fornita usando lo stesso algoritmo/salt;
  • confronto tra hash calcolato e hash memorizzato.

Fin qui tutto normale. Il problema nasce quando, per certe combinazioni di algoritmo/salt e lunghezza input, il calcolo dell’hash non restituisce un digest “valido”, ma un valore speciale (un sentinel) usato per segnalare errore.

La soglia critica: perché “256 byte” conta

Il dettaglio ricorrente in questa famiglia di bug è una soglia: intorno a 256 byte. Sotto quel limite, l’hash si comporta come atteso. Superato il limite (ad esempio 257 byte o più), alcune implementazioni possono entrare in un percorso anomalo.

In scenari basati su musl libc (frequente su Alpine e su diversi ambienti embedded), la funzione crypt() può restituire "*" (asterisco) per indicare errore o input non gestibile.

Ed ecco il punto: se anche il valore “di riferimento” contro cui si sta confrontando finisce per essere "*", il confronto può risultare positivo.

Non è una “collisione crittografica”. È un bug logico: due errori che si sommano e diventano un successo.

Quando può succedere davvero: la combinazione di precondizioni

Non basta incollare 300 caratteri a caso su qualunque server. L’exploitabilità dipende da condizioni abbastanza restrittive (da qui uno score alto ma non massimo).

In particolare, tende a richiedere:

  1. Autenticazione via password abilitata in sshd
    Se usi solo chiavi (impostazione ormai comune), la superficie si riduce drasticamente.

  2. PAM disabilitato (o non in uso)
    In molte configurazioni, PAM introduce un percorso di verifica differente, che interrompe la catena che porta al comportamento errato.

  3. Presenza di almeno un account locale con hash “moderno” (es. $5$ / $6$)
    L’idea è che, in assenza di un account target valido, si finisca per “pescare” salt/parametri da un account esistente.

  4. Account target non esistente
    Questa è una delle parti più controintuitive: l’attacco può basarsi su un lookup che fallisce (utente inesistente) e su un fallback che poi innesca la comparazione sbagliata.

  5. Ambiente/distribuzione vulnerabile
    Alcune combinazioni tipiche: Alpine Linux (specie versioni più vecchie), OpenWRT o immagini con musl/busybox e specifiche versioni di OpenSSH.

È importante leggerla così: la vulnerabilità non è un “premi un tasto e sei root”, ma una finestra che si apre solo quando più decisioni tecniche si allineano.

Esempio realistico: container Alpine e root login

Un caso didattico frequente è un container Docker basato su Alpine con openssh-server installato e PermitRootLogin yes. Se in più:

  • PasswordAuthentication yes
  • PAM non interviene
  • esiste almeno un utente locale con password hashata (creato ad hoc)

…allora si può riprodurre il comportamento anomalo: più tentativi con password errata falliscono, ma un input molto lungo oltre soglia può innescare il bypass.

Nota pratica: molte distribuzioni hanno già backportato patch, quindi la riproduzione spesso richiede immagini Alpine più vecchie e una versione di OpenSSH vulnerabile.

Perché è “naive” (e perché proprio per questo è pericolosa)

È una vulnerabilità “ingenua” perché:

  • non rompe la crittografia;
  • non richiede tecniche avanzate;
  • sfrutta un caso limite classico: gestione errori + confronto.

Ma è anche pericolosa perché:

  • la password è un input controllato dall’attaccante;
  • l’exploit può essere banale (incollare una stringa lunga);
  • in ambienti embedded/IoT le configurazioni “comode” (password, root login, PAM assente) sono ancora diffuse.

Mitigazioni consigliate (ordine di efficacia)

1) Aggiorna OpenSSH e la base image

La mitigazione migliore è la più noiosa: upgrade.

  • Aggiorna l’immagine Alpine a una versione recente (le patch risultano backportate su molte release dopo un certo punto).
  • Aggiorna OpenSSH e riavvia sshd (se resti con un demone vecchio in memoria non hai risolto nulla).

2) Disabilita l’autenticazione via password

Se puoi, imposta:

PasswordAuthentication no

e adotta solo chiavi (magari con AuthorizedKeysCommand, from=, command= ecc. per policy più strette).

3) Riduci i privilegi d’accesso

Se non è indispensabile:

PermitRootLogin no

Meglio autenticarsi come utente non privilegiato e usare escalation controllata (quando serve).

4) Verifica PAM e la tua pipeline di autenticazione

In ambienti dove PAM è presente, controlla davvero quale percorso sta usando sshd (password diretta vs PAM). La difesa qui è evitare combinazioni “fragili” e uniformare l’autenticazione.

Implicazioni operative: cosa controllare oggi nei tuoi sistemi

Se gestisci infrastruttura o immagini per sviluppo, la checklist minima è:

  • quali host/container hanno PasswordAuthentication yes?
  • dove è consentito PermitRootLogin yes?
  • stai usando Alpine/musl in contesti esposti su rete?
  • hai immagini Docker “pinnate” a versioni vecchie per compatibilità?

Nel mondo frontend capita più spesso di quanto sembri: pipeline CI/CD, ambienti di preview, container di build, bastion interni. Un sshd infilato “temporaneamente” in un’immagine può rimanere lì per anni.

Sintesi

Questa vulnerabilità è un promemoria utile: la sicurezza non crolla solo per attacchi sofisticati, ma anche per una gestione imperfetta dei casi limite.

La lezione pratica è semplice e molto concreta: non esporre SSH con password quando non serve, evita root login, e mantieni aggiornate base image e OpenSSH. Se devi per forza accettare password, allora la manutenzione (patch) e l’hardening della configurazione diventano parte del “contratto” operativo del servizio.