La premessa, che tutti dovrebbero ricordare, è quella inserita all’inizio dell’annuncio di Qualys che presenta una vulnerabilità battezzata regreSSHion:

OpenSSH is one of the most secure software in the world; this vulnerability is one slip-up in an otherwise near-flawless implementation. Its defense-in-depth design and code are a model and an inspiration, and we thank OpenSSH's developers for their exemplary work.

OpenSSH è uno dei software più sicuri al mondo; questa vulnerabilità è un incidente di percorso in una implementazione praticamente impeccabile. Il suo design defense-in-depth ed il suo codice sono un modello e un’ispirazione e ringraziamo gli sviluppatori di OpenSSH per il loro lavoro esemplare.

Non è una precisazione da poco, perché aiuta a contestualizzare quello che segue, ossia la CVE-2024-6387, una vulnerabilità di tipo race condition, ossia che non si presenta puntualmente, bensì casualmente: se un client non si autentica entro la tempistica indicata in secondi dall’opzione LoginGraceTime (che di default è 120 e nelle versioni più antiche di OpenSSH invece 600), allora l’handler che si chiama SIGALRM viene chiamato in modalità asincrona arrivando per una serie di circostanze (dettagliate nel report) a fornire un veicolo di attacco remoto per potenziali attaccanti, capaci di eseguire codice mediante utente root.

Il problema, come si intuisce dal nome, è in realtà una regressione di una vecchia CVE, risalente addirittura al 2006, ossia CVE-2006-5051, ma la novità di questa nuova versione risiede nel come sia stata dimostrata la violazione.

Il lunghissimo post scende in numerosissimi dettagli tecnici, ma la sostanza del discorso è che la problematica è reale e quindi l’aggiornamento dei propri sistemi è caldamente consigliato.

Se avete Ubuntu, ad esempio, il prompt del comando apt vi presenterà questa dicitura:

# OpenSSH CVE-2024-6387 has been fixed for 22.04 LTS, 23.10 and 24.04 LTS.
# RegreSSHion: Possible RCE Due To A Race Condition In Signal Handling.
# For more details see: https://ubuntu.com/security/notices/USN-6859-1.

Ma chiaramente tutte le distribuzioni hanno già provveduto a fornire i pacchetti che risolvono il problema e che lo mitigano, vedi ad esempio la pagina MachineConfig to mitigate CVE-2024-6387 di Red Hat o la pagina CVE-2024-6387 Common Vulnerabilities and Exposures di SUSE, così come CVE-2024-6387 di Debian.

Insomma, tutti sono al corrente ed hanno già provveduto alla produzione delle soluzioni, non rimane che adottarle o controllare, mediante lo script Python CVE-2024-6387_Check, quali macchine della vostra rete sono affette da questa problematica, potreste trovarvi con situazioni simili a questa:

E dover arrivare a questa:

Ultima nota di colore: immaginate i comandi di cui sopra lanciati in un datacenter ancora popolato da macchine CentOS 7, che per forza di cose non possono essere aggiornate… Ma non può essere dai, non ci sarà nessuno così miope da utilizzare una distribuzione non mantenuta in produzione… Giusto?

Buone patch a tutti!