Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime e Analisi Vulnerabilità
Qualcosa non tornava. Una patch molto diffusa nel mondo Linux, applicata sopra OpenSSH da varie distribuzioni, nascondeva un comportamento imprevisto. Non un bug rumoroso, di quelli che saltano subito agli occhi ma una falla che si manifesta solo quando certi percorsi di errore vengono attraversati.
E la cosa curiosa è che tutto nasce da un piccolo dettaglio di codice.
Una funzione utilizzata al posto di un’altra.
Sembra poco, e invece cambia completamente il risultato finale.
Il problema riguarda una patch utilizzata da diverse distribuzioni per supportare il meccanismo GSSAPI Key Exchange. A scoprirlo è stato il ricercatore Jeremy Brown, che ha individuato un difetto nella gestione degli errori all’interno del ciclo server GSSAPI KEX.
La patch utilizza la funzione sshpkt_disconnect(). Solo che… non termina il processo. In pratica inserisce un messaggio di disconnessione nella coda e poi continua l’esecuzione. Il codice però era stato progettato come se venisse chiamata un’altra funzione, ssh_packet_disconnect(), che invece interrompe completamente il processo. Ed è qui che la storia prende una piega strana.
A causa di questa differenza, il flusso di errore può proseguire in una sezione che legge una variabile di stack non inizializzata, chiamata recv_tok. Non esattamente il tipo di variabile che vorresti manipolare in un processo privilegiato. Quel valore viene poi inviato tramite IPC al monitor privilegiato del sistema. E non solo. Successivamente viene passato alla funzione gss_release_buffer(), che potrebbe persino eseguire una free() su un puntatore casuale.
Il risultato? Comportamenti imprevedibili.
Su sistemi x86_64 sono stati osservati crash affidabili del processo figlio, con segnali come SIGSEGV o SIGABRT. In alcuni casi si parla di blocchi SSH fino a circa 90 secondi.
C’è di più.
La vulnerabilità può essere attivata con un singolo pacchetto SSH appositamente costruito di circa 300 byte. Nessuna autenticazione richiesta. Nessuna credenziale. Un aspetto interessante riguarda il contenuto della variabile non inizializzata. Il valore di recv_tok dipende molto dal compilatore utilizzato, dal livello di ottimizzazione e dalle opzioni di build.
Per esempio, compilazioni con Clang senza ottimizzazioni possono lasciare residui di stack molto piccoli. Con GCC e altre opzioni, invece, è possibile ottenere addirittura indirizzi validi dell’heap con lunghezze molto più grandi, fino a oltre 120 KB. Questo significa che l’impatto può cambiare parecchio da una build all’altra. In alcuni scenari si tratta di crash. In altri, di possibili corruzioni dell’heap o di trasferimento di dati di memoria verso il processo privilegiato.
Il problema è stato identificato come CVE-2026-3497.
La correzione suggerita è piuttosto semplice: sostituire sshpkt_disconnect() con ssh_packet_disconnect() nei tre punti del codice server presenti nel file kexgsss.c. I dettagli tecnici completi della scoperta sono stati pubblicati, che ha condiviso il report originale del ricercatore insieme alla patch utilizzata nelle distribuzioni Ubuntu.
Per la community di Red Hot Cyber, questa vicenda ricorda una cosa che chi lavora nella sicurezza sa bene: le patch locali applicate ai software upstream possono diventare terreno fertile per problemi sottili. Non perché siano fatte male, ma perché spesso evolvono nel tempo in contesti diversi. E quando una piccola funzione cambia comportamento… il resto del codice continua ad assumere che nulla sia cambiato.
Spoiler: Tenete sempre gli SSH dentro la vostra rete e mai esposti su Internet.
