Simple Science

Hochmoderne Wissenschaft einfach erklärt

# Computerwissenschaften# Software-Entwicklung# Kryptographie und Sicherheit

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


Fuzzing-Bewertung mussFuzzing-Bewertung mussverbessert werden.Fuzzing-Recherche in Software.Fokus auf bessere Praktiken für
Inhaltsverzeichnis

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:

  1. 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.

  2. Ziele: Die für die Evaluierung verwendeten Ziele sollten relevant und vielfältig sein. Dazu gehören bekannte Fehlermesswerte und reale Anwendungen.

  3. 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.

  4. 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.

  5. 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:

  1. Detaillierte Dokumentation: Autoren sollten eine klare Dokumentation ihrer Methoden bereitstellen, einschliesslich der Einrichtung, Parameter und Versionen aller verwendeten Tools.

  2. Verwendung realer Ziele: Bewertungen sollten echte Anwendungen und Benchmarks nutzen, die praktische Szenarien widerspiegeln.

  3. Faire Vergleiche: Sicherstellen, dass alle verglichenen Fuzzer unter ähnlichen Bedingungen arbeiten, einschliesslich Ressourcenallokation und Seed-Sets.

  4. Standardisierte Metriken: Überall sollten allgemein akzeptierte Metriken in Bewertungen verwendet werden, um die Leistung konsistent zu messen.

  5. Statistische Strenge: Statistische Testmethoden anwenden und Effektgrössen berichten. Das bestätigt, dass die Ergebnisse nicht nur Zufall sind.

  6. Feedback und Validierung: Es ist wichtig, Feedback von Entwicklern zu gefundenen Fehlern und Schwachstellen einzubeziehen. Das hilft sicherzustellen, dass die Ergebnisse legitim sind.

  7. 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.

Originalquelle

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.

Mehr von den Autoren

Ähnliche Artikel