Negli ultimi mesi OpenSSH è tornato a far parlare di sé per alcune vulnerabilità legate al parsing degli input: caratteri di controllo nello username, terminatori \0 in URI ssh://, possibili injection attraverso vecchie funzionalità come ProxyCommand.
Bug definiti da molti esperti “minori”, quasi routine.
Eppure, valutando nel concreto in modo pragmatico, emerge una domanda più profonda:
come è possibile che nel 2025 siamo ancora vulnerabili a problemi che ricordano l’informatica degli anni ’80?
Noi pensiamo che – oggi – il problema non stia nel singolo errore, ma nella storia stessa di OpenSSH.
Precisiamo per evitare fraintendimenti che OpenSSH è uno dei pilastri assoluti della sicurezza informatica moderna, e che tutti coloro che hanno contribuito al progetto – in ogni ambito – sono da ringraziare.
Per moltissimi anni OpenSSH ha reso possibile l’accesso remoto sicuro a server, infrastrutture critiche, sistemi cloud e dispositivi industriali.
Ha resistito a zero-day, attacchi state-sponsored, pressioni geopolitiche e vinto “guerre silenziose” che il grande pubblico non conoscerà mai.
Ma nessuna tecnologia può sopravvivere per così tanto tempo senza portarsi dietro un fardello pesante.
E la lista delle vulnerabilità maggiori lo dimostra:
- 2001 – L’exploit CRC32 in SSH1: un overflow banale, ma sufficiente per ottenere accesso remoto senza autenticazione.
- 2003–2005 – PAM, GSSAPI e ChallengeResponse: quando la complessità aumenta, i bug seguono a ruota.
- 2008 – CVE-2008-5161: il costo della retrocompatibilità crittografica.
- 2015 – Agent hijacking: un singolo socket esposto, identità rubate.
- 2020 – Timing leak sull’enumerazione utenti: una regressione nata da codice storico.
- 2024–2025 – Caratteri di controllo e null byte: vulnerabilità “da 1980” che riaffiorano nel client SSH.
Il pattern è chiaro: in generale, non è il protocollo SSH ad essere fragile, ma tutto ciò che gli ruota attorno, come l’integrazione con la shell, la compatibilità con PAM, il forwarding, parsing di opzioni storiche, l’architettura UNIX sottostante, con pty, setuid, TTY e altri relitti di un’epoca remota.
OpenSSH ha basi solide, ma è anche cresciuto per livelli successivi, strato su strato, fino a diventare un componente che interagisce com molti altri componenti di sistema… e complicato.
Il coraggio di guardare oltre OpenSSH
Forse occorre iniziare a guardare oltre OpenSSH; possiamo continuare a basare l’accesso primario ai sistemi (anche più critici del mondo) su un’architettura nata nel 1999 e radicata su meccanismi degli anni ’70?
Noi crediamo che molti componenti di OpenSSH siano ormai “rami secchi”, impossibili da tagliare senza far crollare l’intero albero odierno della compatibilità. È un software che ha fatto miracoli, ma oggi gli stiamo chiedendo troppo.
Spesso è l’unico “bastione” tra un gruppo di hacker “state sponsored” ed un sistema critico.
WireGuard: la prova che reinventare la ruota non solo è possibile, ma necessario
Prima di WireGuard, il mondo delle VPN sembrava immutabile. OpenVPN era ovunque, IPsec un labirinto di configurazioni. Tutti lo accettavano obtorto collo, e ben pochi ne erano davvero felici.
Poi un giovane sviluppatore decise che quelle ruote non erano più adatte al viaggio; che l’unico modo per migliorare davvero fosse ripartire da zero.
Senza eredità. Senza compromessi. Senza portarsi dietro “modalità legacy”.
WireGuard è nato così: qualche migliaio di righe di codice pulito, crittografia moderna, niente rami secchi.
Un progetto coraggioso e che ha cambiato il mondo VPN in pochi anni.
Oggi WireGuard è nel kernel Linux, più veloce e semplice, adottato ovunque, sinonimo di VPN moderna.
Perché qualcuno ha avuto l’audacia di fare ciò che nessuno osava: reinventare la ruota.
E se fosse il momento di far nascere un nuovo progetto SSH?
Ribadiamo che questo post non vuole criticare OpenSSH.
Anzi, è un omaggio a ciò che ha significato per un’intera generazione di professionisti ed in generale per tutta la comunità IT mondiale.
Ma vuole anche piantare un seme.
Perché l’innovazione, quella vera, quella che cambia i paradigmi, nasce sempre così: da una domanda scomoda, da un dubbio, da un atto di coraggio.
OpenSSH ha protetto il mondo per decenni.
Forse è il momento di iniziare a immaginare quello che lo proteggerà nei prossimi venti.
Noi vorremmo un progetto che sia sicuro by design & by default, che consenta solo a colui che detiene la chiave di accesso di aprire la porta, indipendentemente dalla vulnerabilità degli n. componenti sottostanti del sistema operativo.