Verbesserung der Fuzzing-Bewertungen für bessere Softwarequalität
In diesem Artikel geht's um die Notwendigkeit besserer Bewertungsmethoden in der Fuzzing-Forschung.
― 6 min Lesedauer
Inhaltsverzeichnis
- Die Bedeutung der Evaluierung im Fuzzing
- Evaluierungsmethoden und Metriken
- Beobachtungen aus der Literatur
- Fallstudien von Fuzzing-Papieren
- 1. MemLock und einzigartige Abstürze
- 2. SoFi und übertriebene Schwachstellen
- 3. DARWIN und fehlende Basislinien
- 4. FuzzJIT und nicht reproduzierbare Messungen
- 5. EcoFuzz und ungewöhnliche Metriken
- 6. PolyFuzz und unklare Dokumentation
- 7. FishFuzz und unfairer Abdeckungsmassstab
- Beste Praktiken für zukünftige Bewertungen
- Fazit
- Originalquelle
- Referenz Links
Fuzzing ist eine Methode, um Fehler in Software zu finden. In den letzten zehn Jahren ist es zu einer allgemein akzeptierten Methode geworden, um die Softwarequalität zu verbessern. Unternehmen und grosse Softwareprojekte, wie Browser oder Betriebssysteme, nutzen Fuzzing in ihren Entwicklungsprozessen.
Fuzzing funktioniert, indem man zufällige oder unerwartete Eingaben an ein Programm sendet, um Fehler zu erkennen. Wenn das Programm abstürzt oder sich unerwartet verhält, könnte das auf einen Fehler hindeuten, der behoben werden muss.
Die Bedeutung der Evaluierung im Fuzzing
Obwohl Fuzzing nützlich ist, werden nicht alle Bewertungen von Fuzzing-Methoden richtig durchgeführt. Um die Gültigkeit der Ergebnisse sicherzustellen, müssen Forscher zeigen, wie ihre Methoden im Vergleich zu bestehenden abschneiden. Das erfordert eine gründliche Evaluierungseinrichtung, die klare Metriken und Kontrollen für Variablen in der Testumgebung umfasst.
Viele Studien, die über Fuzzing veröffentlicht wurden, mangeln an sorgfältigen Evaluierungspraktiken. Sie folgen möglicherweise nicht den festgelegten Richtlinien, was zu unzuverlässigen Ergebnissen führen kann. Es ist entscheidend, dass die Forschung in diesem Bereich Reproduzierbar ist, was bedeutet, dass andere Forscher die Studien wiederholen und ähnliche Ergebnisse erzielen können.
Evaluierungsmethoden und Metriken
Die Bewertung von Fuzzing-Methoden sollte bestimmten Empfehlungen folgen, um nützliche Ergebnisse zu liefern:
Basislinien: Ein neuer Fuzzing-Methoden sollte mit einer relevanten Basislinie verglichen werden. Das gibt den Kontext für die Verbesserung, die die neue Methode bietet.
Ziele: Die für die Evaluierung verwendeten Ziele sollten relevant und vielfältig sein. Dazu gehören bekannte Fehlermesswerte und reale Anwendungen.
Einrichtungsparameter: Aufgrund der zufälligen Natur des Fuzzing sollten Tests mehrere Male wiederholt werden, um eine zuverlässige Leistungsbeurteilung zu erhalten. Eine längere Laufzeit, idealerweise 24 Stunden oder mehr, wird empfohlen, um die Leistung angemessen zu bewerten.
Evaluierungsmetriken: Ergebnisse sollten sich nicht nur auf indirekte Massnahmen wie Codeabdeckung stützen. Stattdessen sollte die Bewertung auf der Fähigkeit basieren, Fehler direkt zu entdecken.
Statistische Evaluierung: Statistische Tests können helfen zu bestimmen, ob beobachtete Unterschiede in der Leistung auf Zufälligkeit oder tatsächliche Verbesserungen zurückzuführen sind. Eine ausreichende Anzahl von Versuchen, idealerweise 30, sollte durchgeführt werden.
Beobachtungen aus der Literatur
Forscher haben mehrere Fuzzing-Papiere von renommierten Konferenzen überprüft und erhebliche Mängel festgestellt. Viele Bewertungen halten sich nicht an die festgelegten Richtlinien. Häufige Probleme sind:
- Zu wenige Wiederholungen von Tests, was zu unzuverlässigen Schlussfolgerungen führt.
- Mangel an statistischen Tests und das Versäumnis, die Unsicherheit der Ergebnisse zu messen.
- Verwendung informeller oder künstlich erstellter Datensätze anstelle von realen Zielen.
- Die Dokumentation bietet nicht immer klare Erklärungen zu den Methoden oder Ergebnissen.
Fallstudien von Fuzzing-Papieren
Um die Probleme bei den Fuzzing-Bewertungen hervorzuheben, wurden mehrere Fallstudien zu Papieren aus der Literatur durchgeführt:
1. MemLock und einzigartige Abstürze
MemLock berichtet über die Verwendung von Speicherverbrauch für seine Fuzzing-Methode, um Fehler durch Ressourcenerschöpfung zu identifizieren. Allerdings dokumentieren die Autoren nicht vollständig, wie sie die Laufzeitumgebung verändert haben, was die Leser irreführen könnte. Ihre Abhängigkeit von einzigartigen Abstürzen als Erfolgsmetrik ist ebenfalls problematisch, da sie kein genaues Mass für gefundene Fehler liefert.
2. SoFi und übertriebene Schwachstellen
SoFi behauptete, mehrere Schwachstellen in beliebten Browser-Engines entdeckt zu haben. Allerdings wurden alle gemeldeten Schwachstellen von den Entwicklern zurückgewiesen. Das wirft Bedenken hinsichtlich der Integrität der Ergebnisse und der Bedeutung der Validierung von Ergebnissen mit Feedback von tatsächlichen Softwarepflegern auf.
3. DARWIN und fehlende Basislinien
DARWIN konzentrierte sich auf die Verbesserung der Mutationsplanung, stellte aber keine konsistenten Basislinienvergleiche zur Verfügung. Die im Papier präsentierten Ergebnisse waren nicht reproduzierbar, was einen Bedarf an klarerer Dokumentation und besseren Vergleichen mit bestehenden Tools zeigt.
4. FuzzJIT und nicht reproduzierbare Messungen
FuzzJIT behauptet Verbesserungen in der Codeabdeckung, liefert aber keine reproduzierbaren Ergebnisse. Der Mangel an Details in der Methodik erschwert es anderen, die Ergebnisse zu überprüfen.
5. EcoFuzz und ungewöhnliche Metriken
EcoFuzz führte eine neue Methode zur Messung des Erfolgs basierend auf der Anzahl gefundener Pfade ein. Allerdings hat dieser Ansatz die Leser in die Irre geführt, da er den Eindruck erweckte, dass mehr Pfade eine bessere Abdeckung bedeuteten. Das Papier lieferte nicht genügend Beweise zur Vergleich seiner Leistung mit gängigen Metriken.
6. PolyFuzz und unklare Dokumentation
Die Dokumentation für PolyFuzz war unklar, insbesondere hinsichtlich der Seed-Sets, die in den Experimenten verwendet wurden. Das kann die Ergebnisse erheblich beeinflussen und die Reproduzierbarkeit erschweren.
7. FishFuzz und unfairer Abdeckungsmassstab
FishFuzz präsentierte eine Methode zur Messung der Abdeckung, die versehentlich einen unfairen Vorteil gegenüber Wettbewerbern verschaffte. Durch die Einbeziehung von Abdeckungsinstrumentierungen, die andere Fuzzer nicht verwendeten, verzerrte es die Ergebnisse.
Beste Praktiken für zukünftige Bewertungen
Basierend auf den Erkenntnissen aus Literaturstudien und Fallanalysen können mehrere beste Praktiken für die Bewertung von Fuzzing-Methoden vorgeschlagen werden:
Detaillierte Dokumentation: Autoren sollten eine klare Dokumentation ihrer Methoden bereitstellen, einschliesslich der Einrichtung, Parameter und Versionen aller verwendeten Tools.
Verwendung realer Ziele: Bewertungen sollten echte Anwendungen und Benchmarks nutzen, die praktische Szenarien widerspiegeln.
Faire Vergleiche: Sicherstellen, dass alle verglichenen Fuzzer unter ähnlichen Bedingungen arbeiten, einschliesslich Ressourcenallokation und Seed-Sets.
Standardisierte Metriken: Überall sollten allgemein akzeptierte Metriken in Bewertungen verwendet werden, um die Leistung konsistent zu messen.
Statistische Strenge: Statistische Testmethoden anwenden und Effektgrössen berichten. Das bestätigt, dass die Ergebnisse nicht nur Zufall sind.
Feedback und Validierung: Es ist wichtig, Feedback von Entwicklern zu gefundenen Fehlern und Schwachstellen einzubeziehen. Das hilft sicherzustellen, dass die Ergebnisse legitim sind.
Reproduzierbare Artefakte: Forscher sollten ihren Quellcode und experimentelle Artefakte teilen, damit andere ihre Arbeit effektiv reproduzieren können.
Fazit
Fuzzing bleibt eine wichtige Technik, um Fehler in Software zu finden. Allerdings müssen die Evaluierungspraktiken rund um die Fuzzing-Forschung verbessert werden. Durch die Befolgung bewährter Praktiken und die Einhaltung etablierter Richtlinien können Forscher sicherstellen, dass ihre Ergebnisse nicht nur gültig, sondern auch reproduzierbar sind. Das wird die Vertrauenswürdigkeit von Fuzzing-Methoden und ihren Beitrag zur Softwarequalität erhöhen.
In Zukunft ist es wichtig, dass die Gemeinschaft diese Empfehlungen für bessere Forschungspraktiken annimmt. Eine gründliche Evaluierung kann zu bedeutenden Fortschritten im Bereich der Software-Sicherheit und Zuverlässigkeit führen.
Titel: SoK: Prudent Evaluation Practices for Fuzzing
Zusammenfassung: Fuzzing has proven to be a highly effective approach to uncover software bugs over the past decade. After AFL popularized the groundbreaking concept of lightweight coverage feedback, the field of fuzzing has seen a vast amount of scientific work proposing new techniques, improving methodological aspects of existing strategies, or porting existing methods to new domains. All such work must demonstrate its merit by showing its applicability to a problem, measuring its performance, and often showing its superiority over existing works in a thorough, empirical evaluation. Yet, fuzzing is highly sensitive to its target, environment, and circumstances, e.g., randomness in the testing process. After all, relying on randomness is one of the core principles of fuzzing, governing many aspects of a fuzzer's behavior. Combined with the often highly difficult to control environment, the reproducibility of experiments is a crucial concern and requires a prudent evaluation setup. To address these threats to validity, several works, most notably Evaluating Fuzz Testing by Klees et al., have outlined how a carefully designed evaluation setup should be implemented, but it remains unknown to what extent their recommendations have been adopted in practice. In this work, we systematically analyze the evaluation of 150 fuzzing papers published at the top venues between 2018 and 2023. We study how existing guidelines are implemented and observe potential shortcomings and pitfalls. We find a surprising disregard of the existing guidelines regarding statistical tests and systematic errors in fuzzing evaluations. For example, when investigating reported bugs, ...
Autoren: Moritz Schloegel, Nils Bars, Nico Schiller, Lukas Bernhard, Tobias Scharnowski, Addison Crump, Arash Ale Ebrahim, Nicolai Bissantz, Marius Muench, Thorsten Holz
Letzte Aktualisierung: 2024-05-16 00:00:00
Sprache: English
Quell-URL: https://arxiv.org/abs/2405.10220
Quell-PDF: https://arxiv.org/pdf/2405.10220
Lizenz: https://creativecommons.org/licenses/by/4.0/
Änderungen: Diese Zusammenfassung wurde mit Unterstützung von AI erstellt und kann Ungenauigkeiten enthalten. Genaue Informationen entnehmen Sie bitte den hier verlinkten Originaldokumenten.
Vielen Dank an arxiv für die Nutzung seiner Open-Access-Interoperabilität.
Referenz Links
- https://github.com/fuzz-evaluator/guidelines
- https://github.com/fuzz-evaluator/statistics
- https://github.com/fuzz-evaluator/
- https://github.com/fuzz-evaluator/MemLock-Fuzz-eval
- https://github.com/fuzz-evaluator/DARWIN-eval
- https://github.com/fuzz-evaluator/fuzzjit-eval
- https://github.com/fuzz-evaluator/EcoFuzz-eval
- https://github.com/fuzz-evaluator/PolyFuzz-eval
- https://github.com/fuzz-evaluator/firmafl-eval/
- https://github.com/fuzz-evaluator/FishFuzz-eval