Gebruiker:Wicoby/Kladblok

Een voorbeeld van machinetaal, in hexadecimale cijfers geschreven. Deze taal kan de processor van een computer meteen uitvoeren. Een software wordt meestal niet in deze taal geschreven. Een van de eerste fuzzingmethodes was hierop gebaseerd.

Fuzzing of fuzzing-testen is een techniek voor het testen van software die ongeldige, onverwachte of willekeurige data invoert in een computerprogramma. Het programma wordt daarna in de gaten gehouden voor verwachtingen zoals crashen, falende ingebouwde codepredikaten of het vinden van mogelijke geheugenlekken. Fuzzing wordt vooral gebruikt voor het testen van beveiligingsproblemen in software of in besturingssystemen.

geschiedenis

Ontstaan van de term

De term "fuzzing" of fuzz-testen" komt origineel van een klasproject in 1988. Deze klas werd gegeven door Barton Miller aan de the University of Wisconsin. Het klasproject ontwikkelde een basisopdrachtregelprogramma fuzzer om de betrouwbaarheid van Unix-programma's te testen. De test werd herhaald in 1995. Toen werd de test uitgebreid om ook op GUI-gebaseerde tools(zoals bijvoorbeeld het X Window System), netwerkprotocollen en systeembibliotheek API's te testen. De navolgende werken bevatten het testen van commando- en GUI-gebaseerde applicaties op zowel Windows als Mac OS X.

Vroegere voorbeelden

• Een van de eerste voorbeelden van fuzzing dateerd van 1983. Steve capps ontwikkelde een Macintosh applicatie genaamd "the monkey". De applicatie maakte gebruik van journaling codes om willekeurige data in te brengen in Mac-programma's. Het werd ook gebruikt om bugs te testen in MacPaint.

• Een ander voorbeeld van fuzz-test-gereedschap was crashme, voor het eerst uitgebracht in 1991, was bedoeld om de robuustheid van Unix en Unix-achtige besturingssystemen te testen door het uitvoeren van willekeurige machine-instructies.

Technieken

2 categorieën

De fuzzing-programma's vallen uiteen in 2 categorieën:

1. Op mutatie-gebaseerde fuzzers: ze doen bestaande datastalen muteren om nieuwe data te creëren.
2. Op generatie-gebaseerde fuzzers: ze definiëren nieuwe testdata op basis van modellen van input.

Verschillende vormen

Voorbeeld van command-line-interface

De simpelste vorm van fuzzing is het zenden van een willekeurige stroom bits naar de software, als: Command-line-interface, als willekeurig gemuteerde protocolpakketten of als evenementen. Deze techniek van willekeurige data te zenden, blijft een krachtig middel om bugs te vinden in Command-line-interface, netwerkprotocollen en op GUI-gebaseerde applicaties en diensten. Dit valt dus onder de op generatie-gebaseerde fuzzers.

Een andere veel voorkomende gemakkelijke techniek is het muteren van bestaande input (e.g. bestanden van een integratietest) door bits willekeurig om te draaien of door blokken van het bestand te verplaatsen. Echter, de meest succesvolle fuzzers hebben een gedetailleerde kennis over het formaat of het protocol dat wordt getest. Dit valt dus onder de op mutatie-gebaseerde fuzzers.

Er bestaat ook de "smart-fuzzing"-techniek ( ook bekend als: robuustheidstest, syntactische test, spellingstest of foute (input) injectie). Een op specificatie-gebaseerde fuzzer houdt in dat een volledige reeks van specificaties wordt geschreven in een gereedschap. Dan wordt op model-gebaseerde generatietesttechnieken in het volledig aflopen door de specificaties en het toevoegen van abnormaliteiten van de data's inhoud, structuur, berichten en sequenties.

De protocolaandachtigheid kan ook heuristisch gecreëerd worden op basis van voorbeelden door gebruik te maken van tools zoals Sequitur. Deze fuzzers kunnen testcasussen genereren uit het niets. Of ze kunnen voorbeelden muteren op basis van test suites of uit het echt. Ze kunnen zich concentreren op geldige of ongeldige input, met 'bijna volledig geldige' input die de 'diepste' fouten eruit haalt.

Er zijn 2 limieten aan op protocol-gebaseerde fuzzing gebaseerd op protocolimplementatie van gepubliceerde specificaties:

1. Het testen kan niet doorgaan tot de specificaties een relatieve maturiteit hebben, sinds een specificatie een eerste vereiste is om zo'n fuzzer te schrijven.
2. Vele bruikbare protocollen zijn gepatenteerd of bevatten gepatenteerde uitbreidingen van gepubliceerde protocollen. Als fuzzing dan enkel gebaseerd is op gepubliceerde specificaties, dan zal de testomvang voor de nieuwe of gepatenteerde protocollen beperkt tot onbestaande zijn .

Combinatie met andere testtechnieken

Fuzzing kan ook gecombineerd worden met andere technieken.

• White-box fuzzing maakt gebruik van 'symbolische uitvoering' en van 'verzadigende beperkingen'.
• Evolutionaire fuzzing maakt gebruik van feedback heuristische (e.g. code-omvang in grey-box harnessing) of een gemodelleerde aanvallers gedrag in black-box harnessing)om effectief de aanpak van verkennende testen te automatiseren.

Gebruik

Methodiek

Fuzz-testen wordt vaak gebruikt als een blackboxtest in grote softwareprojecten, waar er een budget bestaat om testtool te ontwikkelen. Fuzz-testen biedt een kosten-batenanalyse voor vele programma's.

De techniek kan slechts een aselecte steekproef voorzien van het systeems gedrag. En in veel gevallen kan het slagen van een fuzz-test alleen aantonen dat een stukje software uitzonderingen aankan zonder te crashen, in plaats van correct gedrag. Dit betekent fuzz-testen algehele kwaliteit verzekert, in plaats van een bug-finding tool, en geen vervanging is voor uitgebreide tests of formele methoden.

Als een ruw meetinstrument voor betrouwbaarheid kan fuzzing voorstellen welke delen van het programma bijzondere aandacht moet krijgen in de vorm van een code audit, statische code analyse of gedeeltelijke herschrijving.

Soorten bugs

een voorbeeld van een programma dat zichzelf debugt

• Evenals het testen voor volledige crashes, kunnen fuzz-testen ook gebruikt worden om bugs te vinden zoals mislukte beweringen en geheugenlekken (indien gekoppeld met een geheugendebugger ). De methode is handig voor grote toepassingen, waarbij eender welke bug de geheugenveiligheid kan beïnvloeden heel waarschijnlijk een ernstige kwetsbaarheid is.

• Sinds fuzzing vaak ongeldige invoer genereert, wordt het gebruikt voor het testen van foutieve afhandelingsroutines, die belangrijk zijn voor software die zijn input niet kan beheersen. Eenvoudige fuzzing kan van gezien worden als een manier om negatieve testen te automatiseren.

• Fuzzing kan ook een aantal vormen van "correctheid"bugs vinden. Zo kan het worden gebruikt om foute serialisatiebugste vinden door het klagen wanneer programma's serializer iets uitzendt dat het programma's parser verwerpt. Het kan ook onbedoelde verschillen tussen twee versies van een programma vinden of tussen twee implementaties van dezelfde specificatie.

Voortplanting en isolatie

Testcasevermindering is het proces van minimale testcases te extraheren uit een originele testcase. Testcasevermindering kan manueel worden gedaan, of met behulp van softwaretools, en meestal gaat om een verdeel-en-heers-algoritme , waarin delen van de test één voor één verwijderd worden, totdat alleen de essentiële kern van de testcase blijft.

Om fouten te kunnen reproduceren, zal de fuzzing-software vaak de invoergegevens dat ze produceert bijhouden, meestal voordat ze het toepast in de software. Als de computer volledig crasht bijft de data bewaart. Als de fuzz-stroom pseudowillekeurig nummergegenereerd is, kan de zaadwaarde worden opgeslagen om de fuzz-poging te reproduceren. Zodra een bug wordt gevonden, zullen sommige fuzzing-software helpen om een testcase te bouwen, die wordt gebruikt voor debugging, gebruik makend van testcaseverminderingshulpmiddelen zoals Delta of Lithium.

Voor- en nadelen

Voordelen

Een voorbeeld van een bug

• bugs gevonden met fuzz-testen zijn soms ernstig, uitbuitbare bugs dat kan worden gebruikt door een echte aanvaller. Ontdekkingen zijn meer gewoonte geworden omdat fuzz-testen meer algemeen gekend is, zoals dezelfde technieken en tools nu gebruikt worden door aanvallers om toegepaste software te misbruiken. Dit is een groot voordeel ten opzichte van binaire of bron-auditing, of zelfs fuzzing's dichte neef, de foute (input) injectie, die vaak gebaseerd op kunstmatige foutieve omstandigheden die moeilijk of onmogelijk uit te buiten zijn.

• Fuzz-testen verbetert de softwarebeveiliging en de softwareveiligheid omdat het vaak vreemd vergissingen en gebreken vindt die de menselijke testers niet zouden vinden, en zelfs voorzichtig mens-test ontwerpers zouden falen om hiervoor tests te ontwikkelen.

Nadelen

• Het grootste probleem met fuzzing om programmafouten te vinden is dat het over het algemeen slechts zeer eenvoudige fouten vindt. De uitvoerende complexiteit van de software testproblemen is van exponentiële orde en elke fuzzer neemt snelkoppelingen om iets interessants te vinden in een tijdsbestek waar een mens om geeft. Een primitieve fuzzer kan een slechte code-omvang hebben ; bijvoorbeeld als de input een controlesom bevat die niet goed aangepast is om andere willekeurige veranderingen aan te kunnen, dan zal alleen de controlesom-validatiecode worden geverifieerd. Code-omvanginstrumenten worden vaak gebruikt om in te schatten hoe "goed" een fuzzer werkt, maar dit zijn slechts richtlijnen voor de kwaliteit van de fuzzer. Van elke fuzzer kan worden verwacht dat ze een andere set van bugs vinden.

• De willekeur van inputs gebruikt in fuzzing wordt vaak gezien als een nadeel, omdat het vangen van een grenswaardeomstandigheid met willekeurige input zeer onwaarschijnlijk is. Maar de meeste fuzzers vandaag de dag lossen dit probleem op met behulp van deterministische algoritmen op basis van de gebruiker zijn inputs.

Referenties

In het Nederlands vallen geen bronnen te vinden; de bronnen hieronder zijn allemaal in het Engels.