L'IA scopre un bug di 27 anni nel codice TCP SACK di OpenBSD

Un sistema di scoperta di vulnerabilità basato sull'IA ha riportato alla luce un bug di 27 anni nel codice di rete del sistema operativo OpenBSD, sottolineando i limiti della difesa basata sulle patch mentre l'intelligenza artificiale cambia la velocità con cui vengono trovati i difetti di sicurezza. Il bug era un errore di confronto tra interi con segno nell'implementazione TCP SACK di OpenBSD, che gestisce le selective acknowledgments (conferme selettive), un meccanismo che permette al ricevente di comunicare al mittente quali parti di un flusso di dati ha già ricevuto, così da ritrasmettere solo le parti mancanti. Niels Provos, esperto di sicurezza informatica con un dottorato presso l'Università del Michigan e ruoli professionali in Google, Stripe e Lacework, ha originariamente scritto il codice nel novembre 1998. L'errore poteva causare una dereferenziazione NULL e un panic del kernel, la parte centrale di un sistema operativo che gestisce hardware e risorse di sistema. Il 7 aprile 2026, l'agente Mythos di Anthropic ha individuato il difetto, esattamente dodici anni dopo la divulgazione pubblica di OpenSSL Heartbleed. Provos, scrivendo come uno dei fondatori di Activ8te, nota che il gruppo ha commemorato lo stesso anniversario con una canzone dance pop chiamata Heartbleed.

Trent'anni fa, trovare una tale vulnerabilità dipendeva da una persona che leggeva il codice giusto. Provos ricorda che nel 1996 lesse il sorgente di TCP Wrappers di Wietse Venema, notò un difetto che coinvolgeva opzioni di source-routing lasche, costruì un attacco e in seguito lo dimostrò dal vivo a HIP'97. L'advisory di Secure Networks Inc. seguì nel febbraio 1997, accreditato a Provos tramite Oliver Friedrichs, rendendo quella la prima data certa della sua ricerca sulle vulnerabilità. Oggi un sistema di IA fa lo stesso lavoro in modo autonomo. Mythos ha analizzato il sorgente del kernel e ha individuato il bug. Provos afferma di aver riprodotto indipendentemente il risultato con il suo framework open-source IronCurtain contro Opus 4.7, Sonnet 4.6 e GLM 5.1 open-weight di Z.AI. Il suo post precedente dettaglia i meccanismi di orchestrazione, ma il punto chiave è che la scoperta di vulnerabilità è un problema di orchestrazione, non un problema di modelli di frontiera.

IronCurtain è open source, quindi la capacità non è né un segreto del difensore né un'arma dell'attaccante. Provos sostiene che l'assunzione di base corretta è la parità sulle capacità. La disciplina che colma il divario con la capacità di frontiera è una macchina a stati finiti, un controllore del flusso di lavoro che non è esso stesso un grande modello linguistico. Instrada agenti specializzati attraverso stati predeterminati: analizza, ipotizza, costruisci harness, valida e classifica. Ogni stato inizia con una finestra di contesto fresca ricostruita da un journal append-only su disco. Gli stati possono emettere solo verdetti da un insieme fisso, e i loop limitati hanno limiti di visita; se un'indagine si blocca, viene escalata a un umano invece di permettere al modello di terminare la corsa dichiarando un falso 'sembra a posto'. Il flusso di lavoro non richiede pesi di frontiera. GLM 5.1 open-weight servito da Z.AI ha guidato la scoperta autonoma su una libreria fondamentale senza controllo manuale. Il modello è grande e non gira su un laptop, ma chiunque possa pagare per un endpoint API o noleggiare un'istanza multi-GPU può guidarlo. Il costo per audit si aggira tra le decine e le poche centinaia di dollari, abbastanza basso da rendere ogni dipendenza in uno stack di produzione nel campo di applicazione della revisione di routine.

Per l'ultimo decennio, la posizione standard del chief information security officer è stata un programma di gestione delle vulnerabilità, SaaS di terze parti per la gestione della postura e il rilevamento delle minacce, e un ciclo di triage che non si svuota mai. Quel modello reggeva finché il tasso di comparsa dei bug era limitato dal lavoro umano disponibile per trovarli. L'IA ha rimosso quel limite. La scoperta ora scala con il credito API, ma il consumo di patch no. La finestra tra la divulgazione e la weaponizzazione continua a ridursi, mentre la finestra tra la disponibilità della patch e la sua propagazione attraverso i consumatori a valle non si riduce. Il secondo modo di fallimento è strutturale: la gestione delle vulnerabilità è reattiva per progettazione. Insegue bug che il mondo ha già scoperto senza eliminare la superficie d'attacco o costruire una difesa in profondità che renderebbe il prossimo meno consequenziale. Provos dice che il vincolo è raramente l'analisi; è il budget, la priorità esecutiva e l'accesso a ingegneri che possono costruire controlli proattivi. Quegli ingegneri erano in scarsa offerta e instradati dalla gravità economica verso una manciata di grandi aziende tecnologiche. Un CISO senza quel talento o budget può finanziare un fornitore e una coda di triage, ma il lavoro proattivo si blocca, e quando si verifica un incidente il CISO è la persona nominata nel postmortem.

La risposta, sostiene Provos, non è trovare bug più velocemente ma costruire infrastrutture che tolgano le classi di attacco dal percorso critico delle decisioni umane di sicurezza in corso. Li chiama invarianti di sicurezza: vincoli imposti dalla macchina applicati coerentemente attraverso un'infrastruttura che impediscono uno o più passaggi della kill chain di un attacco senza richiedere un giudizio umano per ogni incidente. Il bug può ancora esistere; ciò che cambia è se un attaccante può completare la catena. Invece di chiedersi quali bug troverà un avversario, chiediti cosa può fare un avversario dopo aver trovato qualsiasi bug. In un'analisi complementare delle divulgazioni di violazioni pubbliche su securityblueprints.io, Provos ha scoperto che tre invarianti imposti dalla macchina applicati coerentemente avrebbero impedito la maggior parte degli incidenti nel set di dati, nell'ordine del 65%.

L'autenticazione a due fattori hardware sostituisce l'autenticazione a segreto condiviso con la prova crittografica del possesso di un dispositivo registrato. Rimuove il phishing delle credenziali come vettore di accesso iniziale praticabile. Google ha implementato questo internamente a partire dal 2010 circa dopo l'Operazione Aurora e ha riportato zero compromissioni riuscite di phishing delle credenziali di un dipendente da allora. L'esempio ha quindici anni, ma la maggior parte delle aziende usa ancora l'autenticazione a segreto condiviso perché il rollout interrompe le integrazioni legacy costruite sul presupposto che le password siano sufficienti. Il controllo dell'egresso significa negare per impostazione predefinita il traffico di rete in uscita dalla produzione. Un attaccante che compromette un servizio esposto esternamente e ottiene l'esecuzione di codice di solito non ha finito; il danno significativo segue l'arrivo di un payload di seconda fase e la creazione di command-and-control. Il controllo dell'egresso rimuove quel passaggio. Le campagne log4j del dicembre 2021 sono l'illustrazione canonica: ogni sfruttamento dell'accesso iniziale che contava si basava sul fatto che l'host compromesso effettuasse chiamate in uscita per recuperare una fase successiva. Un ambiente di produzione che non può effettuare chiamate in uscita arbitrarie rende l'intera classe di vulnerabilità meno consequenziale, indipendentemente dal fatto che il bug log4j sottostante venga mai patchato su quel particolare host. Il controllo positivo dell'esecuzione significa che solo i binari allowlistati possono essere eseguiti. Gli attacchi di ingegneria sociale in cui un attaccante si spaccia per supporto IT e chiede a un bersaglio di scaricare ed eseguire uno strumento diagnostico diventano strutturalmente impossibili. La macchina del bersaglio rifiuta il binario indipendentemente da quanto sia convincente il pretesto. Microsoft ha fatto la stessa osservazione riguardo a Smart App Control, e diverse grandi aziende hanno costruito allowlist equivalenti internamente per i carichi di lavoro di produzione. Nessuno di questi è recente o nuovo, ma funzionano, hanno funzionato per oltre un decennio nei luoghi che li hanno adottati, e rimuovono una parte sostanziale delle violazioni nel registro pubblico.

Esistono invarianti più forti sotto e sopra questo livello. A livello hardware, il memory tagging al momento dell'allocazione dà al sistema operativo e al runtime una difesa strutturale contro i bug di memory safety della classe heap. L'estensione di tagging della memoria (MTE) di ARM è presente sui dispositivi Pixel oggi. Apple ha annunciato Memory Integrity Enforcement su iOS alla WWDC. Con una piattaforma capace di MTE e un allocatore consapevole dei tag, gli overflow dell'heap che in precedenza producevano corruzione silenziosa ora causano un fault nel momento dell'uso improprio. CHERI è l'estensione di ricerca della stessa idea applicata a livello di capacità. Provos accredita a Dino Dai Zovi la definizione del memory tagging come invariante e l'osservazione che il ciclo di rinnovo hardware può girare più velocemente del ciclo di riscrittura del software: una flotta di dispositivi può assorbire MTE sulla scala dei cicli di rinnovo dei telefoni, mentre riscrivere il mondo del C e C++ in linguaggi più sicuri richiederà molto più tempo.

A livello di applicazione e dati, Context-Aware Data Access (CADA) è l'invariante più forte sviluppato contro il rischio insider. L'accesso ambientale a dati e sistemi sensibili viene rimosso. Ogni lettura o operazione richiede una giustificazione aziendale contemporanea e verificabile, come un ticket di supporto assegnato, e un sistema separato valida che la giustificazione esista e sia aggiornata. Un account operatore compromesso, o un operatore malintenzionato, non può estrarre dati o accedere ai sistemi senza una ragione del mondo reale che un altro sistema può verificare indipendentemente. La forma concreta sono i fornitori di supporto clienti di terze parti. Storicamente, quei fornitori ricevevano strumenti potenti e ampio accesso in lettura a un database clienti, sulla teoria che avrebbero usato l'accesso solo quando necessario. CADA li limita al record del cliente allegato al ticket loro assegnato. Non possono navigare o spostarsi. L'effetto pratico è che l'esposizione da violazione di un singolo account fornitore compromesso crolla dall'intera base clienti a un singolo record. Il costo del compromesso smette di scalare con la dimensione dell'azienda. La compromissione dello strumento amministrativo di Twitter del luglio 2020 è l'illustrazione canonica del modo di fallimento che questo invariante previene. Gli attaccanti hanno ottenuto con l'ingegneria sociale l'accesso allo strumento amministrativo interno e lo hanno usato per dirottare oltre 130 account di alto profilo per una truffa Bitcoin. Il raggio dell'esplosione era determinato dall'ambito dello strumento stesso, che poteva toccare qualsiasi record utente. Context-Aware Data Access rompe questo accoppiamento: un account con privilegio amministrativo può agire solo sui record attualmente collegati a un ticket valido, e l'insieme di tali record è piccolo in ogni momento.

Un ostacolo importante è sempre stato il costo. Progettare, distribuire e mantenere invarianti richiedeva ingegneri specializzati che erano in scarsa offerta e venivano reclutati nella stessa manciata di grandi aziende che avevano già i controlli in atto. Il mercato dei fornitori non ha colmato il divario; vende rilevamento, non invarianti. L'IA sposta l'equazione. Distribuire il controllo dell'egresso richiedeva alcuni ingegneri di sicurezza di piattaforma senior per esaminare l'ambiente, progettare il controllo, distribuirlo incrementalmente e bloccarlo. Con la giusta specifica, un singolo ingegnere assistito dall'IA può fare la maggior parte di quel lavoro. Provos dice che potrebbe scrivere una tale specifica, guidando l'ingegnere da un'indagine sul traffico di produzione attraverso la selezione del substrato di enforcement, la distribuzione in modalità monitor, la generazione della lista di eccezioni e la negazione progressiva, fase per fase. La manutenzione rimane, ma la barriera di budget e talento che ha tenuto gli invarianti fuori dalla maggior parte delle organizzazioni è caduta.

Il giorno dopo il prossimo zero-day, sostiene Provos, l'unica cosa che conterà è se gli invarianti sono stati costruiti in tempo. La scoperta non è più limitata come trent'anni fa. Lo stesso flusso di lavoro che ha riscoperto il suo bug SACK di ventisette anni è open source, funziona contro codice arbitrario e opera senza attrito di uso accettabile nelle mani di un avversario. Non c'è modo di vincere questa corsa sulla cadenza delle patch. La strada da seguire è rendere la classe di bug irrilevante. La gestione delle vulnerabilità continua, a una frazione del peso operativo che porta oggi, mentre l'infrastruttura interrompe la kill chain indipendentemente dai tempi delle patch. Provos ha presentato la registrazione e le diapositive al Cloud Security Alliance AI Summit, e l'articolo è stato originariamente pubblicato sul blog di Niels. Il giorno dopo gli zero-day è un invito a costruire 2FA hardware, egress deny-by-default, esecuzione allowlistata, memory tagging a livello hardware e accesso ai dati context-aware a livello dati. Nessuno è nuovo, ma tutti sono alla portata di un singolo ingegnere con l'IA nel ciclo. Per i lettori che gestiscono siti web o infrastrutture cloud, applicare questi invarianti spesso inizia con la revisione del traffico in uscita consentito e di quali binari possono essere eseguiti; un fornitore di infrastrutture IT e sicurezza come AEU-I può aiutare a valutare e implementare l'egresso deny-by-default e l'esecuzione allowlistata.