Four Ways to Forge a Bundle My Own Verifier Calls Clean: Refusal-Site Mutation Testing of an Evidence-Bundle Verifier

Nel moderno mondo digitale, i sistemi software spesso si affidano a un'idea semplice ma potente: fidati, ma verifica. Quando un programma per computer afferma di aver risolto un problema difficile o di aver analizzato un enorme insieme di dati, produce un rapporto. Per garantire che questo rapporto sia onesto, altri programmi agiscono come auditor. Questi auditor controllano i calcoli, verificano che i file di dati non siano stati manomessi e confermano che i numeri nel riepilogo corrispondano alle prove grezze. Se tutto torna, l'auditor dà il via libera e il risultato viene pubblicato per il mondo intero. Questo processo è la spina dorsale di un software affidabile, permettendo a sconosciuti di fidarsi del lavoro altrui senza bisogno di conoscersi. Tuttavia, affinché questo sistema funzioni, l'auditor stesso deve essere perfetto. Se l'auditor non riesce a individuare una menzogna, o peggio, se dichiara una menzogna come vera senza aver effettivamente esaminato le prove, l'intero sistema crolla. Il pericolo non è solo che un risultato errato passi inosservato, ma che l'auditor possa essere così guasto da approvare un test senza averlo mai eseguito affatto.

Un ricercatore di nome Erik Hill si è proposto di esaminare uno di questi auditor, un programma progettato per verificare pacchetti di prove per un sistema offline. Voleva sapere una domanda specifica e inquietante: quanto spesso questo programma dice "pass" quando in realtà non ha controllato nulla? Per scoprirlo, non si è limitato a cercare bug; ha costruito uno strumento per rompere sistematicamente il proprio auditor. Ha preso ogni singola riga di codice del programma che avrebbe dovuto rifiutare un pacchetto errato e, una alla volta, le ha disattivata. Poi, ha osservato se la suite di test del programma se ne sarebbe accorta. Se i test continuavano a passare dopo la rimozione di una riga di rifiuto, significava che quella riga era un peso morto: non stava effettivamente facendo alcun lavoro. I risultati furono sorprendenti. All'inizio dello studio, due terzi dei punti di rifiuto dell'auditor erano invisibili ai test. Il programma poteva essere privato della maggior parte della sua capacità di dire "no" e continuerebbe comunque a riportare un punteggio perfetto. Era come se un guardiano della sicurezza fosse stato addestrato a controllare oggetti rubati, ma gli esercizi di addestramento non avessero mai incluso un oggetto rubato, quindi il guardiano non avesse mai imparato a cercare uno.

Lo studio iniziò con uno shock da parte di un esperto esterno. Un ingegnere indipendente inviò un pacchetto di prove in cui i numeri principali erano completamente falsi, eppure l'auditor stampò un passaggio perfetto. La frode costò solo quattro byte per essere creata. L'ingegnere aveva sostituito un file con un minuscolo segnaposto vuoto e, poiché l'auditor non aveva controllato che quel file fosse effettivamente presente, ha assunto che tutto fosse a posto. Hill corresse questo specifico buco, ma poi applicò il proprio strumento sistematico al programma riparato. Scoprì che il problema non era solo un errore, ma un modello. Scoprì altri quattro modi per ingannare l'auditor, riscontrando ogni volta che il programma saltava un controllo interamente. Uno di questi trucchi consisteva nel cambiare una singola lettera maiuscola in un'etichetta di gravità, il che causava l'ignoranza del peso di un controllo fallito da parte del programma. Un altro consisteva nel cancellare una chiave da un elenco, causando il salto di un confronto perché l'elemento che doveva essere confrontato era mancante. In ogni caso, il programma non stava fallendo nel compiere un calcolo difficile; stava semplicemente fallendo nell'avviare il calcolo.

Per misurare quanto fosse diffuso questo problema, Hill eseguì il suo strumento di cancellazione contro il codice dell'auditor. Scoprì 112 punti in cui il programma avrebbe dovuto dire "no". Quando li rimosse uno alla volta, 75 di essi potevano essere cancellati senza che alcun test fallisse. Ciò significava che 75 dei 112 punti di rifiuto erano effettivamente invisibili ai controlli di sicurezza del sistema. Il programma aveva un punteggio di 0,330, indicando che solo circa un terzo dei suoi meccanismi di rifiuto veniva effettivamente testato. I restanti due terzi erano "pass vacui": controlli che riportavano il successo anche se non avevano mai esaminato le prove. Questo non è un glitch raro; è un difetto strutturale in cui la rete di sicurezza presenta buchi attraverso i quali nessuno ha mai tentato di cadere. I test stavano controllando che il programma girasse, non che guardasse effettivamente i dati.

Hill testò un approccio comune per risolvere tali problemi: correggere semplicemente i bug specifici che erano stati trovati e aggiungere un test per ciascuno di essi. Corresse le quattro frodi che aveva scoperto e aggiunse nuovi test per garantire che quei trucchi specifici non funzionassero più. Sorprendentemente, questo non migliorò il punteggio di sicurezza complessivo. Il programma aveva ancora gli stessi 75 punti di rifiuto invisibili. I nuovi test coprivano solo i nuovi buchi che aveva appena riparato, lasciando il resto del sistema altrettanto cieco come prima. Fu solo quando cambiò strategia che i numeri si mossero. Invece di correggere i bug, scrisse un nuovo test per ognuna delle incursioni dei 75 punti di rifiuto invisibili, costringendo il programma a dimostrare di poter attivare effettivamente ciascuno di essi. Questo approccio sistematico alzò il punteggio da 0,330 a 1,000, provando che ogni punto di rifiuto poteva effettivamente essere attivato. La lezione era chiara: correggere i bug noti non rende un sistema sicuro; bisogna provare che ogni singolo meccanismo di sicurezza possa effettivamente funzionare.

Lo studio rivelò anche un problema più profondo su come vengono costruiti questi sistemi. Il ricercatore scoprì che l'auditor spesso trattava i rapporti leggibili dall'uomo in modo diverso dai file di dati grezzi utilizzati per i controlli. Quando un pacchetto includeva un rapporto destinato alla lettura umana, l'auditor spesso non verificava che il rapporto corrispondesse ai dati sottostanti. Era come se l'auditor si fidasse del riepilogo ma ignorasse le ricevute. Questo accadeva in diversi progetti differenti, suggerendo un'abitudine comune tra gli sviluppatori: vincolano i dati che il computer controlla, ma lasciano non verificati i dati che gli umani leggono. Il ricercatore scoprì che questo divario permetteva a false affermazioni di passare, dove un rapporto poteva dire "tutti i difetti sono stati corretti" mentre i dati mostravano il contrario.

Durante tutto lo studio, gli strumenti del ricercatore stesso lo tradirono in modi che rispecchiavano lo stesso problema che stava studiando. I suoi strumenti di misurazione a volte riportavano il successo anche quando non stavano misurando nulla. In un caso, uno strumento progettato per rilevare i fallimenti restituì un punteggio perfetto perché la suite di test di base era già fallita, causando al tool di interpretare erroneamente l'errore come un successo. Questo accadde sette volte durante la ricerca, inclusa una volta in cui lo strumento diede un punteggio perfetto mentre il sistema era rotto. Questi fallimenti non furono nascosti; furono documentati nel paper per mostrare che gli strumenti usati per verificare il software sono vulnerabili a questi errori di "pass vuoto" tanto quanto il software che devono controllare.

La conclusione finale del lavoro è un appello a un tipo diverso di testing. Il ricercatore sostiene che non possiamo fare affidamento su una lista di bug noti per mantenere un sistema sicuro. Se un sistema ha un cancello di sicurezza che non è mai stato osservato fallire, non è mai stato osservato funzionare. L'unico modo per esserne certi è testare sistematicamente ogni singolo cancello per garantire che possa effettivamente scattare. Lo studio ha dimostrato che un sistema può apparire perfetto sulla carta pur essendo fondamentalmente rotto nella pratica. Obbligando l'auditor a dimostrare di poter rifiutare i dati errati in ogni modo possibile, il ricercatore ha trasformato un sistema che era cieco ai propri fallimenti in uno pienamente verificato. Il lavoro rimane un monito che, nel mondo della fiducia digitale, l'errore più pericoloso non è un controllo fallito, ma un controllo che non è mai avvenuto affatto.