Nella giornata di ieri è stata pubblicata CVE-2025-61984 una falla in OpenSSH, che permette potenzialmente l’esecuzione di comandi sul client quando ProxyCommand viene usato con nomi utente contenenti caratteri di controllo (per esempio newline).

Alcuni flussi di input in OpenSSH non eliminavano correttamente caratteri di controllo inseriti nei nomi utente. Un attaccante può sfruttare questo comportamento costruendo un nome utente contenente, ad esempio, un newline seguito da una stringa che dovrebbe essere interpretata come comando.

Quando quel nome utente viene inserito nella stringa invocata dal ProxyCommand, alcune shell non si fermano all’errore di sintassi introdotto dal newline e continuano l’esecuzione: la riga successiva può quindi essere eseguita come payload. In sostanza: una piccola sequenza di caratteri malevoli, combinata con una shell permissiva e una certa configurazione SSH, può trasformarsi in RCE.

Perché un submodule Git è pericoloso

GIT può rivelarsi insidioso perché sfrutta azioni ordinarie degli sviluppatori. Un repository può includere un submodule il cui URL SSH è stato costruito per contenere un nome utente manipolato. Quando qualcuno esegue: git clone –recursive

Git prova a recuperare anche i submodule via SSH — ed è in quel momento che il client esegue il ProxyCommand configurato localmente. In determinate condizioni, l’intera catena porta all’esecuzione del payload.

L’exploit infatti non si attiva “da solo”. Per funzionare servono due precise condizioni sul sistema della vittima:

1. Shell permissiva: la shell invocata dal ProxyCommand deve continuare l’esecuzione dopo un errore di sintassi (comportamento tipico di Bash, Fish, csh)
2. ProxyCommand vulnerabile: il file ~/.ssh/config dell’utente deve contenere un ProxyCommand che include il token %r (il nome utente remoto) senza adeguata protezione — ad esempio %r non deve essere correttamente quotato o sanitizzato.

Se entrambe le condizioni si verificano, il nome utente manipolato può essere interpolato nella stringa invocata dal proxy e far partire comandi non voluti.

Implicazioni pratiche

• Sviluppatori e sistemi automatizzati che effettuano clone ricorsivi rappresentano un bersaglio sensibile perché il vettore sfrutta operazioni di routine.
• Strumenti che generano automaticamente ~/.ssh/config e inseriscono %r senza protezioni amplificano il rischio
• La presenza di proof-of-concept pubblici rende la situazione urgente: aumenta la probabilità che qualcuno automatizzi lo sfruttamento su larga scala.

PoC pubblici — cosa mostrano e perché preoccuparsi (informazione non actionabile)

Negli ultimi giorni sono circolati proof-of-concept che spiegano chiaramente la catena d’attacco, ma senza fornire istruzioni pratiche per sfruttarla. Questi PoC mostrano lo scenario tipico: un nome utente contenente caratteri di controllo che viene interpolato nel ProxyCommand, e una shell permissiva che finisce per eseguire la riga successiva. Molti PoC usano come dimostrazione esattamente il caso del submodule Git perché rende evidente il rischio supply-chain: un repository compromesso può raggiungere facilmente sviluppatori e pipeline automatizzate.

Il valore operativo dei PoC non è insegnare come sfruttare, ma mettere in evidenza dove concentrare le verifiche. Tuttavia, la loro pubblicazione riduce il tempo che gli attaccanti impiegherebbero per sviluppare exploit automatici, dunque la finestra per intervenire è breve.
La falla viene risolta aggiornando OpenSSH alla versione 10.1, attività da effettuare quanto prima

L'articolo ProxyCommand: la piccola stringa che apre una porta per gli exploit proviene da il blog della sicurezza informatica.