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

In de moderne digitale wereld vertrouwen softwaresystemen vaak op een simpel maar krachtig idee: vertrouwen, maar verifiëren. Wanneer een computerprogramma beweert een moeilijk probleem te hebben opgelost of een enorme dataset te hebben geanalyseerd, produceert het een rapport. Om te waarborgen dat dit rapport eerlijk is, treden andere programma's op als auditors. Deze auditors controleren de wiskunde, verifiëren of de databestanden niet zijn gemanipuleerd en bevestigen of de cijfers in de samenvatting overeenkomen met het ruwe bewijs. Als alles klopt, geeft de auditor een groen licht en wordt het resultaat gepubliceerd voor de wereld om te zien. Dit proces is de ruggengraat van betrouwbare software, waardoor vreemden elkaars werk kunnen vertrouwen zonder elkaar te hoeven kennen. Echter, voor dit systeem te werken, moet de auditor zelf perfect zijn. Als de auditor er niet in slaagt een leugen te ontdekken, of erger nog, als het een leugen als waarheid verklaart zonder daadwerkelijk naar het bewijs te kijken, stort het hele systeem in. Het gevaar is niet alleen dat een slecht resultaat doorsijpelt, maar dat de auditor zo defect is dat hij een test doorstaat zonder de test überhaupt uit te voeren.

Een onderzoeker genaamd Erik Hill zette zich toe om een dergelijke auditor te onderzoeken, een programma ontworpen om bundels bewijsmateriaal voor een offline systeem te verifiëren. Hij wilde een specifieke, verontrustende vraag weten: hoe vaak zegt dit programma "geslaagd" zonder dat het eigenlijk iets heeft gecontroleerd? Om dat te achterhalen, zocht hij niet alleen naar bugs; hij bouwde een instrument om zijn eigen auditor systematisch kapot te maken. Hij nam elke regel code in het programma die bedoeld was om een slechte bundel af te wijzen, en schakelde ze één voor één uit. Vervolgens keek hij of de testsuite van het programma dit zou merken. Als de tests nog steeds slaagden nadat een afwijzingsregel was verwijderd, betekende dit dat die afwijzingsregel overbodig was—het deed nooit echt werk. De resultaten waren verbijsterend. Aan het begin van de studie was tweederde van de afwijzingspunten van de auditor onzichtbaar voor de tests. Het programma kon gestript worden van het grootste deel van zijn vermogen om "nee" te zeggen, en zou nog steeds een perfecte score rapporteren. Het was alsof een beveiligingsbeambte getraind was om te controleren op gestolen goederen, maar de trainingsoefeningen bevatten nooit een gestolen item, waardoor de beambte nooit leerde om ernaar te kijken.

De studie begon met een schok van een externe expert. Een onafhankelijk ingenieur diende een bundel bewijsmateriaal in waarbij de hoofdcijfers volkomen onjuist waren, maar de auditor drukte toch een perfect geslaagd resultaat af. De fraude kostte slechts vier bytes om te creëren. De ingenieur had een bestand vervangen door een pieklein, leeg tijdelijk bestand, en omdat de auditor er niet in slaagde te controleren of dat bestand daadwerkelijk aanwezig was, nam het aan dat alles in orde was. Hill herstelde deze specifieke fout, maar paste vervolgens zijn eigen systematische instrument toe op het gerepareerde programma. Hij ontdekte dat het probleem niet slechts één fout was, maar een patroon. Hij ontdekte vier andere manieren om de auditor te misleiden, waarbij hij telkens ontdekte dat het programma een controle volledig oversloeg. Een van deze trucs hield in dat een enkele hoofdletter in een ernst-label werd gewijzigd, wat ervoor zorgde dat het programma het gewicht van een mislukte controle negeerde. Een andere methode hield in dat een sleutel uit een lijst werd verwijderd, waardoor het programma een vergelijking oversloeg omdat het item dat het moest vergelijken ontbrak. In elk geval faalde het programma niet in het uitvoeren van een moeilijke berekening; het faalde simpelweg in het starten van de berekening.

Om te meten hoe wijdverspreid dit probleem was, draaide Hill zijn verwijderinstrument tegen de code van de auditor. Hij vond 112 plaatsen waar het programma "nee" zou moeten zeggen. Toen hij deze één voor één verwijderde, konden er 75 worden verwijderd zonder dat een test faalde. Dit betekende dat 75 van de 112 afwijzingspunten effectief onzichtbaar waren voor de veiligheidscontroles van het systeem. Het programma had een score van 0,330, wat aangaf dat slechts ongeveer een derde van de afwijzingsmechanismen daadwerkelijk werd getest. De resterende twee derde waren "vacuüm geslaagd"—controles die succes rapporteerden terwijl ze het bewijs nooit hadden onderzocht. Dit is geen zeldzame glitch; het is een structureel defect waarbij het vangnet gaten heeft waar niemand ooit doorheen is gevallen. De tests controleerden of het programma wel draaide, niet of het daadwerkelijk naar de data keek.

Hill testte vervolgens een gebruikelijke aanpak om dergelijke problemen op te lossen: simpelweg de specifieke bugs die gevonden waren repareren en een test voor elk van hen toevoegen. Hij herstelde de vier vervalsingen die hij had ontdekt en voegde nieuwe tests toe om te garanderen dat die specifieke trucs niet meer zouden werken. Verrassend genoeg verbeterde dit de algemene veiligheidsscore niet. Het programma had nog steeds dezelfde 75 onzichtbare afwijzingspunten. De nieuwe tests dekten alleen de nieuwe gaten die hij zojuist had gedicht, waardoor de rest van het systeem net zo blind bleef als voorheen. Het was pas toen hij zijn strategie veranderde, dat de cijfers veranderden. In plaats van bugs te repareren, schreef hij een nieuwe test voor elk van de 75 onzichtbare afwijzingspunten, waardoor hij het programma dwong te bewijzen dat het elk van hen daadwerkelijk kon activeren. Deze systematische aanpak verhoogde de score van 0,330 naar 1,000, waarmee werd bewezen dat elk afwijzingspunt inderdaad getriggerd kon worden. De les was duidelijk: het repareren van bekende bugs maakt een systeem niet veilig; je moet bewijzen dat elke enkele veiligheidsmechanisme daadwerkelijk kan werken.

De studie onthulde ook een dieper liggend probleem met de manier waarop deze systemen worden gebouwd. De onderzoeker ontdekte dat de auditor menselijke rapporten vaak anders behandelde dan de ruwe databestanden die voor controles worden gebruikt. Wanneer een bundel een rapport bevatte dat bedoeld was voor een mens om te lezen, faalde de auditor er vaak in te verifiëren of het rapport overeenkwam met de onderliggende data. Het was alsof de auditor het samenvattingsblad vertrouwde maar de bonnetjes negeerde. Dit kwam bij meerdere verschillende projecten voor, wat duidt op een veelvoorkomende gewoonte onder ontwikkelaars: zij koppelen de data die de computer controleert, maar laten de data die mensen lezen ongeverifieerd. De onderzoeker vond dat deze kloof ervoor zorgde dat valse claims erdoorheen glipten, waarbij een rapport kon zeggen dat "alle defecten zijn opgelost" terwijl de data het tegendeel bewees.

Gedurende de hele studie faalden de eigen instrumenten van de onderzoeker op manieren die de problematiek die hij bestudeerde weerspiegelden. Zijn meetinstrumenten rapporteerden soms succes, zelfs wanneer ze niets aan het meten waren. In één geval gaf een instrument dat ontworpen was om fouten te detecteren een perfecte score omdat de basis-testsuite al gefaald had, waardoor het instrument de fout verkeerd interpreteerde als een succes. Dit gebeurde zeven keer tijdens het onderzoek, waaronder één keer waarbij het instrument een perfecte score gaf terwijl het systeem defect was. Deze fouten werden niet verborgen; ze werden in het artikel gedocumenteerd om aan te tonen dat de instrumenten die software verifiëren net zo kwetsbaar zijn voor deze "lege succes"-fouten als de software die ze moeten controleren.

De uiteindelijke conclusie van het werk is een oproep tot een ander soort testen. De onderzoeker betoogt dat we niet kunnen vertrouwen op een lijst van bekende bugs om een systeem veilig te houden. Als een systeem een veiligheidshek heeft dat nooit is waargenomen terwijl het faalde, is het nooit waargenomen terwijl het werkte. De enige manier om zeker te zijn, is door systematisch elk hek te testen om te garanderen dat het daadwerkelijk kan functioneren. De studie toonde aan dat een systeem op papier perfect kan lijken terwijl het in de praktijk fundamenteel defect is. Door de auditor te dwingen te bewijzen dat hij slechte data op elke mogelijke manier kon afwijzen, veranderde de onderzoeker een systeem dat blind was voor zijn eigen fouten in een systeem dat volledig geverifieerd was. Het werk staat als een herinnering dat in de wereld van digitaal vertrouwen de gevaarlijkste fout niet een mislukte controle is, maar een controle die helemaal niet heeft plaatsgevonden.