DE102021212597A1

DE102021212597A1 - Speicherbenutzungsbasiertes fuzzing

Info

Publication number: DE102021212597A1
Application number: DE102021212597.2A
Authority: DE
Inventors: Max Camillo Eisele; Christopher Huth
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-11-09
Filing date: 2021-11-09
Publication date: 2023-05-11
Also published as: CN116107866A

Abstract

Ein erster Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum Protokollieren der Speicherzugriffe auf einen Inputbuffer während einer Fuzzing-Iteration einer Software auf einem Hardware-Target, umfassend Generieren von Fuzzing-Eingangsdaten für die Fuzzing-Iteration der Software; Senden der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target, wobei die Fuzzing-Eingangsdaten in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets gespeichert werden; Ausführen der Fuzzing-Iteration der Software auf dem Hardware-Target auf Basis der Fuzzing-Eingangsdaten in dem Inputbuffer; und Protokollieren mindestens eines Speicherzugriffs auf den Inputbuffer während des Ausführens der Fuzzing-Iteration, wobei mindestens ein Speicherort in dem Inputbuffer, der durch das Ausführen der Fuzzing-Iteration auf dem Hardware-Target ausgelesen wird, gespeichert wird.
Ein zweiter, dritter und vierter Aspekt der vorliegenden Offenbarung betreffen computer-implementierte Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target auf Basis mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets.

Description

Stand der Technik
Fuzzing (englisch: fuzzing oder fuzz testing) ist eine automatisierte Technik zum Testen einer Software. Hierbei wird in einer Vielzahl von Fuzzing-Iterationen die Software mit ungültigen, unerwarteten und/oder zufälligen Eingangsdaten ausgeführt und dabei auf Ausnahmen (englisch: exceptions) wie Abstürze, fehlgeschlagene eingebaute Code-Zusicherungen (englisch: assertions), potenzielle Speicherlecks, etc. überwacht. Für Software, deren Eingangsdaten in einer vorbestimmten Datenstruktur vorliegen müssen, können Fuzzer (englisch: fuzzers), die für diese vorbestimmte Datenstruktur ausgelegt sind, zum Einsatz kommen. Die vorbestimmte Datenstruktur ist zum Beispiel in einem Dateiformat und/oder Protokoll spezifiziert. Ein (effizienter) Fuzzer ist dafür ausgelegt, ungültige, unerwartete und/oder zufällige Eingangsdaten in der vorbestimmten Datenstruktur zu generieren, so dass eine Ausführung einer jeweiligen Fuzzing-Iteration der Software ohne Parse-Fehler auf Basis der Eingangsdaten gestartet werden kann. Durch Fuzzing kann insbesondere in komplexer Software (wie z.B. Software für die Steuerung, Regelung und/oder Überwachung eines technischen Systems) unerwartetes Verhalten wie z.B. unerwartete (Progamm)pfade und/oder Programmierfehler sowie Eckfälle ermittelt werden. Durch ein derart erlangtes besseres Softwareverständnis können die Software und insbesondere deren Sicherheit verbessert werden.
Ein Fuzzing-Target kann eine Software (z.B. ein Programm) und/oder ein Teil davon (z.B. eine Funktion) sein, die durch Fuzzing getestet werden soll. Das Fuzzing-Target kann dergestalt sein, dass es potenziell nicht vertrauenswürdige Eingangsdaten akzeptiert, die beim Fuzzing durch einen Fuzzer für eine Vielzahl von Fuzzing-Iterationen generiert werden können. In diesem Zusammenhang kann Fuzzing als der automatisierte Vorgang gesehen werden, beliebige und insbesondere ungültige, unerwartete und/oder zufällige Eingangsdaten an das Fuzzing-Target zu schicken und dessen Reaktion sodann während der Ausführung dieser Fuzzing-Iteration zu beobachten. Der Fuzzer oder die Fuzzing-Maschine ist ein Computer-Programm, das dafür ausgelegt ist, automatisiert Eingangsdaten je Fuzzing-Iteration für das Fuzzing-Target zu generieren. Der Fuzzer ist nicht Teil des Fuzzing-Targets, sondern unabhängig vom Fuzzing-Target. In der Regel sind Fuzzer nicht instrumentiert. Ein bekannter Fuzzer ist zum Beispiel afl oder libfuzzer. Die Kombination aus einem Fuzzing-Target und einem dazugehörigen Fuzzer kann als Fuzzing-Test bezeichnet werden. Der Fuzzing-Test ist ausführbar. Der Fuzzer kann jeweils unterschiedliche Eingangsdaten für eine Vielzahl von Fuzzing-Iterationen - z.B. hunderte oder tausende Fuzzing-Iterationen pro Sekunde - generieren und jeweils einen Fuzzing-Test mit den dazugehörigen Eingangsdaten starten, beobachten, und gegebenenfalls auch anhalten. Eine Fuzzing-Iteration umfasst eine Ausführung des Fuzzing-Targets/der Software ausgehend von für diese Fuzzing-Iteration generierten Eingangsdaten. Durch Speichern der jeweiligen Eingangsdaten, kann die Fuzzing-Iteration, insbesondere, wenn ein unerwartetes Verhalten der Software während der Fuzzing-Iteration (z.B. noch nicht bekannte Pfade und/oder Programmierfehler) erkannt wurde, zu einem späteren Zeitpunkt reproduziert werden, wobei dann das Fuzzing-Target ohne Fuzzer aber auf den gespeicherten Eingangsdaten ausgeführt werden kann.
Während der Ausführung eines Fuzzing-Tests können Informationen aus dem Software-Target ausgegeben werden. Ein solches Softwareabdeckungsfeedback (englisch: coverage-guided fuzzing) kann vorteilhafterweise beim Fuzzing genutzt werden, um noch nicht bekannte Pfade/Blöcke zu erkennen und/oder Programmierfehler in der Software zu lokalisieren. Softwareabdeckungsfeedback beim Fuzzing kann zum Beispiel wie bei afl durch statische Instrumentierung des Fuzzing-Targets realisiert werden. Bei der statischen Instrumentierung wird das Fuzzing-Target - d.h. die Software - (zum Beispiel beim Kompilieren) dahingehend geändert, dass Informationen über zum Beispiel zuletzt ausgeführte Anweisungen in der Software und/oder (Programm)pfade bei der Ausführung der Software und insbesondere während einer Fuzzing-Iteration abgerufen werden können. Alternativ oder zusätzlich kann Softwareabdeckungsfeedback aus einer dynamischen Instrumentierung erlangt werden. Hierbei wird über Systemfunktionalitäten und/oder Emulatoren die Ausführung der Software zur Laufzeit gesteuert, um Informationen über die Abläufe in der Software zu erhalten. Softwareabdeckungsfeedback durch dynamische Instrumentierung ist insbesondere dann vorteilhaft, wenn die Software in kompilierter Form (englisch: closed-source) vorliegt.
Das Generieren von Fuzzing-Eingangsdaten je Fuzzing-Iteration kann zum Beispiel mutationsbasiert sein. Hier können zum Beispiel durch den Fuzzer bereits vorhandene und/oder vorläufige Fuzzing-Eingangsdaten (auch als Seed bezeichnet und z.B. in einem Korpus gespeichert) mutiert werden und dadurch (neue) Fuzzing-Eingangsdaten generiert werden. Solche Mutationen können zum Beispiel zufällig sein. Fuzzer wie zum Beispiel afl, Honggfuzz oder Libfuzzer können für mutationsbasiertes Fuzzing mit Softwareabdeckungsfeedback ausgelegt sein. Solche Fuzzer können zum Beispiel bereits vorhandene Fuzzing-Eingangsdaten, die z.B. für eine frühere Fuzzing-Iteration generiert worden ist, aus dem Korpus auswählen und mutieren lassen. Alternativ können vorläufige Fuzzing-Eingangsdaten für eine nächste Fuzzing-Iteration generiert oder ausgewählt werden und anschließend mutiert werden. In jedem Fall werden so durch den Fuzzer die Fuzzing-Eingangsdaten für die nächste Fuzzing-Iteration generiert und an das Fuzzing-Target (d.h. an die Software auf dem Hardware-Target) gesendet. Zeigt sich zum Beispiel bei der Ausführung der nächsten Fuzzing-Iteration auf Basis solcher Fuzzing-Eingangsdaten ein unerwartetes Verhalten der Software, können diese Fuzzing-Eingangsdaten (als weiterer Seed) in den Korpus gespeichert werden. Mutationsbasiert können sodann weitere Fuzzing-Eingangsdaten für weitere Fuzzing-Iterationen auf Basis der in den Korpus gespeicherten Fuzzing-Eingangsdaten generiert werden. Dadurch kann die Software effizient insbesondere an kritischen Stellen getestet und erkundet werden.
Alternativ oder zusätzlich kann das Generieren von Fuzzing-Eingangsdaten durch den Fuzzer generationenbasiert sein. Hier können zum Beispiel Fuzzing-Eingangsdaten auf Basis eines Inputmodels und/oder einer Input-Grammatik generiert werden. Fuzzer wie z.B. Autogramm oder Mimid können dafür ausgelegt sein, eine Verunreinigungsanalyse (englisch: taint analysis) durchzuführen, wobei eine Input-Grammatik für die Software erzeugt wird, die dann für das Fuzzing genutzt werden kann.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum Protokollieren der Speicherzugriffe auf einen Inputbuffer während einer Fuzzing-Iteration einer Software auf einem Hardware-Target. Das Verfahren umfasst Generieren von Fuzzing-Eingangsdaten für die Fuzzing-Iteration der Software. Das Verfahren umfasst weiterhin Senden der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target, wobei die Fuzzing-Eingangsdaten in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets gespeichert werden. Das Verfahren umfasst weiterhin Ausführen der Fuzzing-Iteration der Software auf dem Hardware-Target auf Basis der Fuzzing-Eingangsdaten in dem Inputbuffer. Das Verfahren umfasst weiterhin Protokollieren mindestens eines Speicherzugriffs auf den Inputbuffer während des Ausführens der Fuzzing-Iteration, wobei mindestens ein Speicherort in dem Inputbuffer, der durch das Ausführen der Fuzzing-Iteration auf dem Hardware-Target ausgelesen wird, gespeichert wird.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target. Das Verfahren umfasst Generieren von vorläufigen Fuzzing-Eingangsdaten. Das Verfahren umfasst weiterhin Auswählen mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren. Das Verfahren umfasst weiterhin Auswählen mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets, wobei Ausführen der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert. Das Verfahren umfasst weiterhin Anwenden des mindestens einen Mutationsoperators auf die vorläufigen Fuzzing-Eingangsdaten, wobei Fuzzing-Eingangsdaten generiert werden. Das Anwenden des mindestens einen Mutationsoperators auf die vorläufigen Fuzzing-Eingangsdaten erfolgt derart, dass nach Senden der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target, bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets gespeichert werden, ein Speicherinhalt in dem mindestens einen Speicherort auf einem Ergebnis des mindestens einen Mutationsoperators basiert.
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein weiteres computer-implementiertes Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target. Das Verfahren umfasst Generieren von vorläufigen Fuzzing-Eingangsdaten. Das Verfahren kann Senden der vorläufigen Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target, wobei die vorläufigen Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets gespeichert werden, umfassen. Das Verfahren umfasst Auswählen mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren. Das Verfahren umfasst Auswählen mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets, wobei Ausführen der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert. Das Verfahren umfasst Anwenden des mindestens einen Mutationsoperators auf einen Speicherinhalt in dem mindestens einen Speicherort, der zumindest auf einem Teil der vorläufigen Fuzzing-Eingangsdaten basiert, wobei Fuzzing-Eingangsdaten im Inputbuffer generiert werden.
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein drittes computer-implementiertes Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target. Das Verfahren umfasst Generieren von Eingangsdaten für ein Inputmodel und/oder für eine Input-Grammatik zum generationsbasierten Generieren von Fuzzing-Eingangsdaten. Das Verfahren umfasst weiterhin Auswählen mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren. Das Verfahren umfasst weiterhin Auswählen mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets, wobei Ausführen der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert. Das Verfahren umfasst weiterhin Anwenden des mindestens einen Mutationsoperators auf die Eingangsdaten, auf das Inputmodel und/oder auf die Input-Grammatik. Das Verfahren umfasst weiterhin Generieren von Fuzzing-Eingangsdaten auf Basis des Inputmodels und/oder auf der Input-Grammatik sowie auf Basis der Eingangsdaten, wobei mindestens eines von Inputmodel, Input-Grammatik und Eingangsdaten durch Anwenden des mindestens einen Mutationsoperators mutiert worden ist. Das Verfahren kann Senden der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target umfassen. Das Anwenden des mindestens einen Mutationsoperators auf die Eingangsdaten, auf das Inputmodel und/oder auf die Input-Grammatik erfolgt derart, dass nach Senden der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target, bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets gespeichert werden, ein Speicherinhalt in dem mindestens einen Speicherort auf einem Ergebnis des mindestens einen Mutationsoperators basiert.
Ein fünfter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-System, das dafür ausgelegt sein kann, das computer-implementierte Verfahren zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen. Alternativ oder zusätzlich kann das Computer-System dafür ausgelegt sein, das (weitere) computer-implementierte Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration der Software auf dem Hardware-Target nach dem zweiten, dritten und/oder vierten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
Ein sechster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-Programm, das dafür ausgelegt sein kann, das computer-implementierte Verfahren zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen. Alternativ oder zusätzlich kann das Computer-Programm dafür ausgelegt sein, das (weitere) computer-implementierte Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration der Software auf dem Hardware-Target nach dem zweiten, dritten und/oder vierten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
Ein siebter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-lesbares Medium oder Signal, das das Computer-Programm nach dem sechsten allgemeinen Aspekt speichert und/oder enthält.
Die in dieser Offenbarung vorgeschlagenen Verfahren sind auf ein spezielles und effizientes Fuzzing einer Software auf einem Hardware-Target gerichtet. Die Verfahren können insbesondere darauf gerichtet sein, Fuzzing-Eingangsdaten für nächste Fuzzing-Iterationen durch speicherbenutzungsbasierte Mutationen von bereits vorhandenen Fuzzing-Eingangsdaten (englisch: memory access aware fuzzing, MAAF) aus vorhergehenden Fuzzing-Iterationen zu generieren. Dabei können durch Speicherzugriffe auf Fuzzing-Eingangsdaten im Inputbuffer des Arbeitsspeichers des Hardware-Targets, die während der Ausführung vorhergehender Fuzzing-Iterationen - nach dem Verfahren des ersten allgemeinen Aspekts (oder einer Ausführungsform davon) - protokolliert worden sind, gezielt Speicherorte in einem Inputbuffer und/oder dazu korrespondierende Bereiche in den bereits vorhandenen Fuzzing-Eingangsdaten - nach dem Verfahren des zweiten oder dritten allgemeinen Aspekts (oder einer Ausführungsform davon) - mutiert werden. Im Gegensatz zum im Stand der Technik bekannten mutationsbasierten Generieren von Fuzzing-Eingangsdaten kann die Software durch die nach den Verfahren dieser Offenbarung generierten Fuzzing-Eingangsdaten gezielt an den Speicherorten im Inputbuffer getestet werden, auf die Speicherzugriffe in vorhergehenden Fuzzing-Iterationen erfolgt sind. Hat zum Beispiel Ausführen der unmittelbar vorhergehenden Fuzzing-Iteration zu einem Programmierfehler wie z.B. einem Absturz der Software geführt, kann gezielt der Speicherort im Inputbuffer, auf den zuletzt vor dem Auftreten des Absturzes ein Speicherzugriff erfolgt ist, durch Mutation geändert werden. Dadurch können zum Beispiel Absturzursachen analysiert werden.
Nicht selten treten im Programmiercode der Software sogenannte Zauberwerte (englisch: magic values) auf. Diese können zum Beispiel dazu genutzt werden, um bestimmte Formate und/oder Daten (in den Fuzzing-Eingangsdaten) zu identifizieren. Zum Beispiel kann ein png-Bild leicht anhand einer vorangestellten Zeichenkette „png“ (bestehend aus drei bytes) identifiziert und von anderen Inhalten unterschieden (zum Beispiel durch ein switch-case Konstrukt) werden. Somit können protokollierte Speicherzugriffe aus vorherigen Fuzzing-Iterationen (auch: Seeds) die Mutationen der vorherigen Fuzzing-Eingangsdaten (auch: Seeds) für nächste Fuzzing-Iterationen direkt beeinflussen. Daher kann im Verfahren des ersten allgemeinen Aspekts (oder einer Ausführungsform davon) für jede Fuzzing-Iteration mindestens ein Speicherzugriff, eine Vielzahl von Speicherzugriffen und/oder alle Speicherzugriffe protokolliert werden. Dabei kann für jeden Speicherzugriff der Speicherort, der zum Beispiel durch ein Startbyte (oder allgemeiner: Offset) im Inputbuffer und einer Bytelänge (oder allgemeiner: Größe des Speicherorts im Inputbuffer) definiert werden kann, protokolliert werden. Zusätzlich können ein Programmcode-Zählerwert der Software bei dem mindestens einen Speicherzugriff, ein Zeitstempel bei dem mindestens einen Speicherzugriff, eine Charakteristik des mindestens einen Speicherzugriffs und/oder Metadaten, die sich auf den mindestens einen Speicherzugriff beziehen protokolliert werden.
Durch die Kenntnis der für die vorhergehenden Fuzzing-Iterationen relevanten Speicherorte können Verzweigungen und insbesondere Bedingungen (z.B. bedingte Sprünge) leichter und somit effizienter und/oder schneller erkundet werden, da die relevanten Speicherorte einen typischerweise deutlich kleineren Unterraum des Gesamtraums aller möglichen Fuzzing-Eingangsdaten repräsentieren. Die Verfahren der vorliegenden Offenbarung ermöglichen somit unterraumfeste Fuzzing-Iterationen, die mit konventionellem mutationsbasiertem Generieren von Fuzzing-Eingangsdaten im Allgemeinen nicht zu bewerkstelligen sind.
Das direkte Einbeziehen der Kenntnis der Speicherzugriffe in die Mutationen zum Generieren der Fuzzing-Eingangsdaten steigert die Fuzzing-Effizienz und/oder die Geschwindigkeit des Fuzzing, da gezielt und schnell Eingangsdaten geändert werden können, die für zu testende und mitunter tief versteckte Funktionalitäten der Software relevant sind. Zum Beispiel können gezielt mutierte Eingangsdaten bestimmte Verzweigungen und/oder Prüfungen in der Software passieren. Das effizientere Fuzzing der Software führt zu einer Verbesserung der Software und insbesondere des durch die Software gesteuerten, geregelten und/oder überwachten technischen Systems (z.B. ein eingebettetes System, eine elektronische Steuereinheit etc.).
Die Verfahren nach dem zweiten oder dritten allgemeinen Aspekt (oder einer Ausführungsform davon) stellen ein spezielles mutationsbasiertes Generieren von Fuzzing-Eingangsdaten dar. Alternativ oder zusätzlich kann die Kenntnis der für die vorhergehenden Fuzzing-Iterationen relevanten Speicherorte zum Beispiel auch auf generationenbasiertes Generieren von Fuzzing-Eingangsdaten übertragen werden. Im Verfahren nach dem vierten allgemeinen Aspekt (oder einer Ausführungsform davon) können zum Beispiel die relevanten Speicherorte auf spezifische Teile des Inputmodels und/oder der Input-Grammatik zugeordnet werden. Alternativ oder zusätzlich können die relevanten Speicherorte auf Eingangsdaten für das Inputmodel und/oder die Input-Grammatik zugeordnet werden. Durch Mutieren solcher spezifischer Teile und/oder solcher zugeordneter Eingangsdaten können wiederum Fuzzing-Eingangsdaten generiert werden, die an den relevanten Speicherorten im Inputbuffer mutiert worden sind. Mutationsbasiertes Generieren und generationenbasiertes Generieren können kombiniert werden. Zum Beispiel können zunächst (vorläufige) Fuzzing-Eingangsdaten generationenbasiert generiert werden, aus denen dann mutationsbasiert Fuzzing-Eingangsdaten generiert werden können.
Figurenliste

1 illustriert schematisch ein computer-implementiertes Verfahren zum Protokollieren der Speicherzugriffe auf einen Inputbuffer während einer Fuzzing-Iteration einer Software auf einem Hardware-Target.
2a illustriert schematisch ein computer-implementiertes Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target.
2b illustriert schematisch ein weiteres computer-implementiertes Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target.
2c illustriert schematisch ein drittes computer-implementiertes Verfahren zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target.
3a illustriert schematisch ein beispielhaftes Flussdiagramm für mutationsbasiertes Fuzzing.
3b illustriert schematisch ein beispielhaftes Flussdiagramm für mutationsbasiertes und speicherbenutzungsbasiertes Fuzzing.
4a illustriert schematisch ein beispielhaftes Flussdiagramm für mutationsbasiertes Fuzzing.
4b illustriert schematisch ein beispielhaftes Flussdiagramm für das Generieren von Fuzzing-Eingangsdaten.

Detaillierte Beschreibung
Die in dieser Offenbarung vorgeschlagenen Verfahren 100, 200a, 200b, 200c ermöglichen effizienteres Fuzzing einer Software (auf einem Hardware-Target). Die Software kann zum Beispiel eine Software sein, die dafür ausgelegt ist, ein eingebettetes System und insbesondere eine elektronische Steuereinheit (z.B. in einem Fahrzeug) zu steuern, zu regeln und/oder zu überwachen. Das Hardware-Target 10 kann zum Beispiel das eingebettete System und insbesondere die elektronische Steuereinheit sein. Die Software kann ausführbaren, kompilierten Programmcode umfassen.
Offenbart wird zunächst ein computer-implementiertes Verfahren 100 zum Protokollieren der Speicherzugriffe auf einen Inputbuffer während einer Fuzzing-Iteration einer Software auf einem Hardware-Target 10. Der Inputbuffer kann ein für die Software fester Speicherbereich in einem Arbeitsspeicher des Hardware-Targets 10 sein. Das kann insbesondere bedeuten, dass die Software bei jeder einer Vielzahl von Fuzzing-Iterationen stets auf denselben Inputbuffer und somit auf denselben Speicherbereich in dem Arbeitsspeicher des Hardware-Targets 10 zugreift. Die Voraussetzung kann zum Beispiel dadurch erfüllt werden, dass die Software zwischen Fuzzing-Iterationen nicht verändert wird und - wie z.B. für sicherheitskritische Software im Fahrzeugbereich - auf dynamische Speicherallokation verzichtet.
Das Verfahren 100, schematisch in 1 dargestellt, kann Generieren 110 von Fuzzing-Eingangsdaten für die Fuzzing-Iteration der Software (durch einen Fuzzer 20) umfassen. Die Fuzzing-Eingangsdaten können durch ein im Stand der Technik bekanntes Verfahren und insbesondere mutationsbasiert und/oder generationsbasiert generiert werden. Alternativ oder zusätzlich können die Fuzzing-Eingangsdaten nach den Verfahren 200a, 200b speicherbenutzungsbasiert generiert werden.
Das Verfahren 100 kann weiterhin Senden 120 der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10, wobei die Fuzzing-Eingangsdaten in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets 10 gespeichert werden, umfassen.
Alternativ (nicht dargestellt in 1) kann das Verfahren 100 Generieren von Fuzzing-Eingangsdaten für die Fuzzing-Iteration der Software in dem Inputbuffer im Arbeitsspeicher des Hardware-Targets 10 umfassen. In diesem Fall kann das Senden 120 der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10 obsolet sein.
Das Verfahren 100 umfasst weiterhin Ausführen 130 der Fuzzing-Iteration der Software auf dem Hardware-Target 10 auf Basis der Fuzzing-Eingangsdaten in dem Inputbuffer. Das kann bedeuten, dass während des Ausführens 130 der Fuzzing-Iteration Fuzzing-Eingangsdaten oder ein Teil davon aus dem Inputbuffer gelesen werden.
Das Verfahren 100 umfasst weiterhin Protokollieren 140 mindestens eines Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration, wobei mindestens ein Speicherort in dem Inputbuffer, der durch das Ausführen 130 der Fuzzing-Iteration auf dem Hardware-Target 10 ausgelesen wird, gespeichert wird. Das Verfahren 100 kann insbesondere auch Protokollieren 140 einer Vielzahl von Speicherzugriffen auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration umfassen. Die Vielzahl von Speicherzugriffen kann zum Beispiel >=2, >=3, >=5, >=10, >=20, >=50, >=100, >=200, >=500, >=le3, >=le4 Speicherzugriffe (während der Fuzzing-Iteration) umfassen. Das Verfahren 100 kann insbesondere auch Protokollieren 140 aller Speicherzugriffe auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration umfassen. Das Protokollieren 140 des mindestens einen Speicherzugriffs kann zum Beispiel in einem Ringbuffer einer vorbestimmten Größe erfolgen. Dadurch kann zum Beispiel sichergestellt werden, dass zumindest der oder die letzten Speicherzugriffe vor Auftreten eines unerwarteten Verhaltens bei der Fuzzing-Iteration der Software protokolliert worden sind. Der protokollierte mindestens eine Speicherzugriff (oder die Vielzahl der protokollierten Speicherzugriffe) kann zum Beispiel wie in einer Ausführungsform des Verfahrens 200a, 200b dafür genutzt werden, Mutationen gezielt auf die (aktuellen) Fuzzing-Eingangsdaten anzuwenden, wobei wiederum Fuzzing-Eingangsdaten für eine weitere Fuzzing-Iteration generiert werden. Alternativ oder zusätzlich kann der protokollierte mindestens eine Speicherzugriff (oder die Vielzahl der protokollierten Speicherzugriffe) wie in einer Ausführungsform des Verfahrens 200c dafür genutzt werden, Mutationen gezielt auf die Eingangsdaten, auf das Inputmodel und/oder auf die Input-Grammatik anzuwenden, wobei wiederum generationenbasiert Fuzzing-Eingangsdaten für eine weitere Fuzzing-Iteration generiert werden.
Das Speichern des mindestens einen Speicherorts in dem Inputbuffer kann Speichern eines Startbytes (oder allgemeiner: Offset) und einer Bytelänge (oder allgemeiner: Größe des Speicherorts im Inputbuffer) umfassen. Das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration kann Speichern eines Programmcode-Zählerwerts der Software bei dem mindestens einen Speicherzugriff umfassen. Alternativ oder zusätzlich kann das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration Speichern eines Zeitstempels bei dem mindestens einen Speicherzugriff umfassen. Alternativ oder zusätzlich kann das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration Speichern einer Charakteristik des mindestens einen Speicherzugriffs umfassen. Alternativ oder zusätzlich kann das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration Speichern von Metadaten, die sich auf den mindestens einen Speicherzugriff beziehen, umfassen. Solche Informationen können jeweils auch für jeden Speicherzugriff (der Vielzahl von Speicherzugriffe) gespeichert werden.
Das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration kann auf statischer Instrumentierung der Software (auf dem Hardware-Target 10) basieren. Alternativ oder zusätzlich kann das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration auf dynamischer Instrumentierung des Hardware-Targets 10 basieren. In anderen Worten: das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration wird durch statische Instrumentierung der Software und/oder durch dynamische Instrumentierung des Hardware-Targets 10 ermöglicht.
Das Verfahren 100 kann, wie in 1 als optionaler Schritt dargestellt, Erhalten 150 von Softwareabdeckungsfeedback während des Ausführens 130 der Fuzzing-Iteration umfassen. Das Softwareabdeckungsfeedback kann zum Beispiel auf der statischen Instrumentierung der Software (auf dem Hardware-Target 10) basieren. Alternativ oder zusätzlich kann das Softwareabdeckungsfeedback auf der dynamischen Instrumentierung des Hardware-Targets 10 basieren.
Das Protokollieren 140 des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens 130 der Fuzzing-Iteration kann Speichern des Softwareabdeckungsfeedbacks umfassen. Die Charakteristik des mindestens einen Speicherzugriffs kann zum Beispiel auf dem Softwareabdeckungsfeedback basieren. Alternativ oder zusätzlich können die Metadaten, die sich auf den mindestens einen Speicherzugriff beziehen, auf dem Softwareabdeckungsfeedback basieren.
Das Verfahren 100 kann, wie in 1 als optionaler Schritt dargestellt, Prüfen 160, während des Ausführens 130 der Fuzzing-Iteration, ob die Fuzzing-Iteration unerwartetes Verhalten zeigt, umfassen. Der mindestens eine protokollierte 140 Speicherzugriff auf den Inputbuffer kann zum Beispiel den letzten Speicherzugriff auf den Inputbuffer, bevor die Fuzzing-Iteration (während der Ausführung) unerwartetes Verhalten zeigt, umfassen. Unerwartetes Verhalten während der Ausführung einer Fuzzing-Iteration kann zum Beispiel eine Abweichung von einem regulären Durchlauf der Fuzzing-Iteration sein. Zum Beispiel kann unerwartetes Verhalten durch einen Programmierfehler und insbesondere durch einen Laufzeitfehler (z.B. Division durch Null, Fehlindizierung, etc.) verursacht werden. Somit kann in diesem Fall das unerwartete Verhalten einen Absturz der Software umfassen. Alternativ oder zusätzlich kann unerwartetes Verhalten ein Erreichen eines noch nicht bekannten (Programm)pfads in der Software umfassen. Alternativ oder zusätzlich kann unerwartetes Verhalten ein noch nicht bekannter Speicherzugriff durch die Software umfassen. Das Prüfen 160, ob die Fuzzing-Iteration unerwartetes Verhalten zeigt, kann auf dem Softwareabdeckungsfeedback basieren.
Ein Pfad in der Software kann zum Beispiel als Pfad in einem abstrakten Syntaxbaum, der die Software repräsentiert, definiert werden. Ein Programmierfehler kann zum Beispiel durch einen Fehler-Code (z.B. zur Unterscheidung von Division durch Null, Index außer Reichweite, etc.) definiert sein. Ein Pfad kann eine Sequenz von Anweisungen der Software sein, die (in der Reihenfolge der Sequenz) beim Ausführen der Software ausgeführt und insbesondere erreicht werden. Die Sequenz kann, aber muss nicht alle Anweisungen der Software, die (in der Reihenfolge der Sequenz) beim Ausführen der Software ausgeführt werden, umfassen. Zum Beispiel kann es (für das Softwareverständnis) ausreichend sein, wenn die Sequenz zumindest Anweisungen umfasst, die jeweils einen Zweig einer Verzweigung (z.B. bei einer Konstruktion if-then-else) eindeutig bestimmen.
Durch das Softwareabdeckungsfeedback kann zum Beispiel ein (gefundener) Pfad und/oder Programmierfehler in der Software lokalisiert werden. Eine solche Information kann zum Beispiel zur Protokollierung bereits bekannter Pfade und/oder Programmierfehler genutzt werden.
Offenbart wird weiterhin ein computer-implementiertes Verfahren 200a zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target 10.
Das Verfahren 200a, schematisch illustriert in 2a, umfasst Generieren 210a von vorläufigen Fuzzing-Eingangsdaten. Die vorläufigen Fuzzing-Eingangsdaten können durch ein im Stand der Technik bekanntes Verfahren und insbesondere mutationsbasiert und/oder generationsbasiert generiert werden. Alternativ oder zusätzlich können die vorläufigen Fuzzing-Eingangsdaten auch nach den/einem der Verfahren 200a, 200b speicherbenutzungsbasiert generiert worden sein. Die vorläufigen Fuzzing-Eingangsdaten können für eine vorhergehende Fuzzing-Iteration der Software generiert worden sein.
Das Verfahren 200a umfasst weiterhin Auswählen 220a mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren. Die Vielzahl der Mutationsoperatoren kann zum Beispiel >= 1, >= 5, >= 10, >= 50, >= 100, >= 500, >= 1e3, >= 5e3, >= 1e4 Mutationsoperatoren umfassen. Ein Mutationsoperator kann eine Funktion sein, die dafür ausgelegt ist, einen Input zu mutieren, wobei ein Output generiert wird, der dieselbe Speicherstruktur hat. Im Allgemeinen kann der Output im Vergleich zum Input verändert worden sein. Ein Mutationsoperator/Funktion kann deterministisch und/oder zufällig sein. Das Verfahren 200a kann insbesondere Auswählen 220a mehrerer Mutationsoperatoren umfassen.
Das Verfahren 200a umfasst Auswählen 230a mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets 10, wobei Ausführen 130 der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert. Das Verfahren 200a kann insbesondere Auswählen 230a einer Vielzahl von Speicherorten in dem Inputbuffer in dem Arbeitsspeicher des Hardware-Targets 10 umfassen.
Das Verfahren 200a umfasst Anwenden 240a des mindestens einen Mutationsoperators auf die vorläufigen Fuzzing-Eingangsdaten, wobei Fuzzing-Eingangsdaten generiert (110) werden. Das Verfahren 200a kann Anwenden 240a der mehreren Mutationsoperatoren auf die vorläufigen Fuzzing-Eingangsdaten umfassen.
Das Anwenden 240a des mindestens einen Mutationsoperators auf die vorläufigen Fuzzing-Eingangsdaten erfolgt derart, dass nach Senden 241a der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10, bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets 10 gespeichert werden, ein Speicherinhalt in dem mindestens einen Speicherort auf einem Ergebnis des mindestens einen Mutationsoperators basiert. Weiterhin kann das Anwenden 240a der mehreren Mutationsoperatoren auf die vorläufigen Fuzzing-Eingangsdaten derart erfolgen, dass nach Senden 241a der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10, bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets 10 gespeichert werden, Speicherinhalte der Vielzahl von Speicherorten auf (jeweiligen) Ergebnissen der mehreren Mutationsoperatoren basieren. In jedem Fall können die so generierten (110) Fuzzing-Eingangsdaten sodann in einer nächsten Fuzzing-Iteration der Software verwendet werden.
Das Verfahren 200a kann, wie in 2a als optionaler Schritt dargestellt, Senden 241a der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10 umfassen. Per Konstruktion können sich somit die nach dem Verfahren 200a generierten Fuzzing-Eingangsdaten an dem mindestens einen Speicherort im Inputbuffer von den vorläufigen Fuzzing-Eingangsdaten unterscheiden.
Alternativ oder zusätzlich wird ein (weiteres) computer-implementiertes Verfahren 200b zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target 10 offenbart.
Das Verfahren 200b, schematisch illustriert in 2b, umfasst Generieren 210b von vorläufigen Fuzzing-Eingangsdaten. Die vorläufigen Fuzzing-Eingangsdaten können zum Beispiel wie im Verfahren 200a generiert werden.
Das Verfahren 200b kann weiterhin, wie in 2b als optionaler Schritt dargestellt, Senden 211b der vorläufigen Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10 umfassen, wobei die vorläufigen Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets gespeichert werden. Das Senden 211b kann zum Beispiel dann obsolet oder implizit sein, wenn die vorläufigen Fuzzing-Eingangsdaten direkt im Inputbuffer des Hardware-Targets 10 generiert werden.
Das Verfahren 200b umfasst weiterhin Auswählen 220b mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren. Die Vielzahl der Mutationsoperatoren kann zum Beispiel >= 1, >= 5, >= 10, >= 50, >= 100, >= 500, >= 1e3, >= 5e3, >= 1e4 Mutationsoperatoren umfassen. Ein Mutationsoperator kann wie im Verfahren 200a eine Funktion sein, die dafür ausgelegt ist, einen Input zu mutieren, wobei ein Output generiert wird, der dieselbe Speicherstruktur hat. Im Allgemeinen kann der Output im Vergleich zum Input verändert worden sein. Ein Mutationsoperator/Funktion kann deterministisch und/oder zufällig sein. Das Verfahren 200b kann insbesondere Auswählen 220b mehrerer Mutationsoperatoren umfassen.
Das Verfahren 200b umfasst weiterhin Auswählen 230b mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets 10, wobei Ausführen 130 der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert. Das Verfahren 200b kann insbesondere Auswählen 230b einer Vielzahl von Speicherorten in dem Inputbuffer in dem Arbeitsspeicher des Hardware-Targets 10 umfassen.
Das Verfahren 200b umfasst weiterhin Anwenden 240b des mindestens einen Mutationsoperators auf einen Speicherinhalt in dem mindestens einen Speicherort, der zumindest auf einem Teil der vorläufigen Fuzzing-Eingangsdaten basiert, wobei Fuzzing-Eingangsdaten im Inputbuffer generiert (110) werden. Der mindestens eine Speicherort kann zumindest auf einem Teil der vorläufigen Fuzzing-Eingangsdaten basieren, wenn der zumindest eine Teil der vorläufigen Fuzzing-Eingangsdaten (als Speicherinhalt) in dem mindestens einen Speicherort des Inputbuffers gespeichert ist oder gespeichert werden kann. Das Verfahren 200b kann insbesondere Anwenden 240b der mehreren Mutationsoperatoren auf Speicherinhalte der Vielzahl von Speicherorten, die zumindest auf einem Teil der vorläufigen Fuzzing-Eingangsdaten basieren, umfassen, wobei ebenfalls Fuzzing-Eingangsdaten im Inputbuffer generiert (110) werden.
Per Konstruktion können sich somit auch die nach dem Verfahren 200b generierten Fuzzing-Eingangsdaten an dem mindestens einen Speicherort im Inputbuffer von den vorläufigen Fuzzing-Eingangsdaten unterscheiden.
Im Gegensatz zum Verfahren 200a erfolgt das Anwenden 240b des mindestens einen Mutationsoperator im Verfahren 200b direkt auf einen Speicherinhalt in dem mindestens einen Speicherort im Inputbuffer des Hardware-Targets 10.
Alternativ oder zusätzlich wird ein (drittes) computer-implementiertes Verfahren 200c zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target 10 offenbart.
Das Verfahren 200c, schematisch illustriert in 2c, umfasst Generieren 210c von Eingangsdaten für ein Inputmodel und/oder für eine Input-Grammatik zum generationsbasierten Generieren von Fuzzing-Eingangsdaten.
Das Verfahren 200c umfasst weiterhin Auswählen 220c mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren. Die Vielzahl der Mutationsoperatoren kann zum Beispiel >= 1, >= 5, >= 10, >= 50, >= 100, >= 500, >= 1e3, >= 5e3, >= 1e4 Mutationsoperatoren umfassen. Ein Mutationsoperator kann wie im Verfahren 200a, 200b eine Funktion sein, die dafür ausgelegt ist, einen Input zu mutieren, wobei ein Output generiert wird, der dieselbe Speicherstruktur hat. Im Allgemeinen kann der Output im Vergleich zum Input verändert worden sein. Ein Mutationsoperator/Funktion kann deterministisch und/oder zufällig sein. Das Verfahren 200c kann insbesondere Auswählen 220c mehrerer Mutationsoperatoren umfassen.
Das Verfahren 200c umfasst weiterhin Auswählen 230c mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets 10, wobei Ausführen (130) der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert. Das Verfahren 200c kann insbesondere Auswählen 230c einer Vielzahl von Speicherorten in dem Inputbuffer in dem Arbeitsspeicher des Hardware-Targets 10 umfassen.
Das Verfahren 200c kann weiterhin Anwenden 240c des mindestens einen Mutationsoperators auf die Eingangsdaten umfassen. Alternativ oder zusätzlich kann das Verfahren 200c Anwenden 240c des mindestens einen Mutationsoperators auf das Inputmodel (oder auf Teile davon) und/oder auf die Input-Grammatik (oder auf Teile davon) umfassen. Das Verfahren 200c kann Anwenden 240c der mehreren Mutationsoperatoren auf die Eingangsdaten umfassen. Alternativ oder zusätzlich kann das Verfahren 200c Anwenden 240c der mehreren Mutationsoperatoren auf das Inputmodel (oder auf Teile davon) und/oder auf die Input-Grammatik (oder auf Teile davon) umfassen.
Das Verfahren 200c umfasst weiterhin Generieren 250c von Fuzzing-Eingangsdaten auf Basis des Inputmodels und/oder auf der Input-Grammatik sowie auf Basis der Eingangsdaten, wobei mindestens eines von Inputmodel, Input-Grammatik und Eingangsdaten durch Anwenden 240c des mindestens einen Mutationsoperators mutiert worden ist.
Das Anwenden 240c des mindestens einen Mutationsoperators auf die Eingangsdaten, auf das Inputmodel und/oder auf die Input-Grammatik erfolgt dabei derart, dass nach Senden 251c der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10, bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets 10 gespeichert werden, ein Speicherinhalt in dem mindestens einen Speicherort auf einem Ergebnis des mindestens einen Mutationsoperators basiert.
Das Verfahren 200c kann, wie in 2c als optionaler Schritt dargestellt, Senden 251a der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target 10 umfassen.
Das Auswählen 230a, 230b, 230c des mindestens einen Speicherorts in dem Inputbuffer (oder einer Vielzahl von Speicherorten darin) kann umfassen: Auswählen mindestens eines Speicherorts in dem Inputbuffer (oder der Vielzahl der Speicherorten darin), der nach dem computer-implementierten Verfahren 100 zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target 10 gespeichert worden ist. In diesem Fall kann die Fuzzing-Iteration aus dem Verfahren 100 als eine vorherige Fuzzing-Iteration und die Fuzzing-Eingangsdaten aus dem Verfahren 100 als vorherige Fuzzing-Eingangsdaten bezeichnet werden. Die vorherige Fuzzing-Iteration kann aber muss nicht die letzte Fuzzing-Iteration sein. Ebenso können aber müssen nicht die vorherigen Fuzzing-Eingangsdaten die letzten Fuzzing-Eingangsdaten sein. Dadurch können, ausgehend von bereits vorhandenen Fuzzing-Eingangsdaten aus vorherigen Fuzzing-Iterationen, die Fuzzing-Eingangsdaten für eine nächste (oder allgemeiner: weitere) Fuzzing-Iteration gezielt mutiert werden und somit die Software gezielt getestet und erkundet werden. Die weitere Fuzzing-Iteration kann aber muss nicht die nächste Fuzzing-Iteration sein.
3a illustriert schematisch ein beispielhaftes Flussdiagramm für konventionelles mutationsbasiertes Fuzzing. Der darin dargestellte Fuzzer 20 ist an das Hardware-Target 10 bzw. an die Software auf dem Hardware-Target 10 gekoppelt und ist dafür ausgelegt, Fuzzing-Eingangsdaten der Software auf dem Hardware-Target 10 bereitzustellen. Durch z.B. Softwareabdeckungsfeedback kann die Ausführung der Software auf dem Hardware-Target 10 vom Fuzzer 20 überwacht werden. Der Fuzzer 20 kann bereits vorhandene Fuzzing-Eingangsdaten (hier als Seed bezeichnet) aus einem Korpus 30 auswählen, der Teil oder nicht Teil des Fuzzers 20 sein kann. Der Korpus 30 kann zum Beispiel eine Datenbank sein und/oder in einer bestimmten Speicherstruktur gespeichert sein. Ausgewählte Fuzzing-Eingangsdaten können durch den Fuzzer 20 mutiert und in einer Fuzzing-Iteration der Software auf dem Hardware-Target 10 erprobt werden. Nach einem vorbestimmten Kriterium können die Fuzzing-Eingangsdaten in dem Korpus 30 gespeichert werden, z.B. dann, wenn die Software bei Ausführung der Fuzzing-Iteration ein unerwartetes Verhalten (z.B. ein noch nicht bekannter Pfad und/oder ein noch nicht bekannter Speicherzugriff) gefunden worden ist. Zusätzlich können Metadaten, die zum Beispiel aus dem Feedback des Hardware-Targets 10 resultieren, im Korpus 30 gespeichert werden. Das Feedback kann zum Beispiel durch statische/dynamische Instrumentierung oder durch Emulation erlangt werden.
3b illustriert schematisch ein beispielhaftes und ausgehend von dem Flussdiagramm aus 3a angepasstes Flussdiagramm für mutationsbasiertes und speicherbenutzungsbasiertes Fuzzing. Werden Fuzzing-Eingangsdaten (oder ein Seed) in dem Korpus 30 gespeichert, kann zusätzlich mindestens ein Speicherort im Inputbuffer des Hardware-Targets 10 im Korpus 30 mit abgespeichert werden. Der oder die Speicherorte können als Speicherzugriffsmuster abgespeichert werden. Das Speicherzugriffsmuster kann zum Beispiel aus einer Sequenz einem oder mehreren Elementen bestehen, wobei jedes Element ein Startbyte (oder Offset), eine Bytelänge (oder Größe des Speicherorts) und gegebenenfalls weiteren Daten umfasst. Die weiteren Daten können zum Beispiel einen Programmcode-Zählerwert der Software bei dem jeweiligen Speicherzugriff, einen Zeitstempel bei dem jeweiligen Speicherzugriff, eine Charakteristik des jeweiligen Speicherzugriffs und/oder Metadaten, die sich auf den jeweiligen Speicherzugriff beziehen, umfassen. Der mindestens eine Speicherzugriff kann zum Beispiel durch statische Instrumentierung der Software und/oder aus dynamischer Instrumentierung des Hardware-Targets 10 erfolgen. Zum Beispiel kann der Fuzzer 20 Fuzzing-Eingangsdaten und das dazugehörige Speicherzugriffsmuster aus dem Korpus 30 auslesen. Durch Anwenden des mindestens einen Mutationsoperators 240a, 240b, 240c können gezielt die Fuzzing-Eingangsdaten für eine nächste Fuzzing-Iteration an den Stellen mutiert werden, die im Inputbuffer des Hardware-Targets 10 den durch das Speicherzugriffsmuster definierten Speicherorten entsprechen. Zum Beispiel kann die Stelle des letzten Speicherzugriffs der vorhergehenden Fuzzing-Iteration mutiert werden. Dabei können Werte in dem zum letzten Speicherzugriff dazugehörigen Speicherort zum Beispiel inkrementiert und/oder in anderer Weise (z.B. zufällig) geändert werden. Alternativ oder zusätzlich kann beispielsweise eine (zufällige) Auswahl aller Speicherorte, auf die die vorhergehende Fuzzing-Iteration zugegriffen hat, getroffen werden und auf Basis dieser Auswahl die Fuzzing-Eingangsdaten mutiert werden.
4a illustriert schematisch ein beispielhaftes Flussdiagramm für mutationsbasiertes Fuzzing, in das die Verfahren 200a, 200b, 200c zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target 10 integriert werden können. Dazu kann eine Architektur von Fuzzer 20, Korpus 30 und Hardware-Target 10 wie in 3b genutzt werden.
Weiterhin illustriert 4b schematisch ein beispielhaftes (Unter)flussdiagramm für das Generieren von Fuzzing-Eingangsdaten, das als eine beispielhafte Implementierung der Box „Fuzzing-Eingangsdaten generieren“ aus 4a gesehen werden kann. Wie in 4b dargestellt, kann zwischen konventionellem mutationsbasiertem Generieren von Fuzzing-Eingangsdaten und speicherbenutzungsbasiertem Generieren von Fuzzing-Eingangsdaten nach Verfahren 200a, 200b, 200c (zufällig) abgewechselt werden. Dadurch kann die Leistungsfähigkeit des mutationsbasierten Fuzzers 20 weiterhin genutzt werden. Zum Beispiel können eine oder mehrere Fuzzing-Iterationen auf Basis von jeweiligen Fuzzing-Eingangsdaten durchgeführt werden, die durch den Fuzzer 20 mutationsbasiert generiert worden sind. Eine oder mehrere nächste Fuzzing-Iterationen können dann zum Beispiel auf Basis von speicherbenutzungsbasiert (aus vorhergehenden Fuzzing-Iterationen) und/oder mutationsbasiert generierten Fuzzing-Eingangsdaten durchgeführt werden. Verschiedene Fuzzing-Strategien können implementiert werden.
Offenbart wird weiterhin ein Computer-System, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target 10 auszuführen.
Alternativ oder zusätzlich kann das Computer-System (oder (je) ein weiteres Computer-System) dafür ausgelegt sein, jedes oder jede Kombination von den computer-implementierten Verfahren 200a, 200b, 200c zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration der Software auf dem Hardware-Target 10 auszuführen.
Das Computer-System (oder das weitere Computer-System) kann einen Prozessor und/oder einen Arbeitsspeicher umfassen.
Offenbart wird weiterhin ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target 10 auszuführen. Alternativ oder zusätzlich kann das Computer-Programm (oder (je) ein weiteres Computer-Programm) dafür ausgelegt sein, das computer-implementierte Verfahren 200a, 200b, 200c zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration der Software auf dem Hardware-Target 10 auszuführen.
Das Computer-Programm (oder das/jedes weitere Computer-Programm) kann z.B. in interpretierbarer oder in kompilierter Form vorliegen. Es kann (auch in Teilen) zur Ausführung z.B. als Bit- oder Byte-Folge in den RAM eines Computers geladen werden.
Offenbart wird weiterhin ein computer-lesbares Medium oder Signal, das das Computer-Programm speichert und/oder enthält. Das Medium kann z.B. eines von RAM, ROM, EPROM, HDD, SDD, ... umfassen, auf/in dem das Signal gespeichert wird.

Claims

Computer-implementiertes Verfahren (100) zum Protokollieren der Speicherzugriffe auf einen Inputbuffer während einer Fuzzing-Iteration einer Software auf einem Hardware-Target (10), umfassend: - Generieren (110) von Fuzzing-Eingangsdaten für die Fuzzing-Iteration der Software; - Senden (120) der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target (10), wobei die Fuzzing-Eingangsdaten in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets (10) gespeichert werden; - Ausführen (130) der Fuzzing-Iteration der Software auf dem Hardware-Target (10) auf Basis der Fuzzing-Eingangsdaten in dem Inputbuffer; - Protokollieren (140) mindestens eines Speicherzugriffs auf den Inputbuffer während des Ausführens (130) der Fuzzing-Iteration, wobei mindestens ein Speicherort in dem Inputbuffer, der durch das Ausführen (130) der Fuzzing-Iteration auf dem Hardware-Target (10) ausgelesen wird, gespeichert wird.
Verfahren (100) nach Anspruch 1, wobei das Speichern des mindestens einen Speicherorts in dem Inputbuffer Speichern eines Startbytes und einer Bytelänge umfasst.
Verfahren (100) nach Anspruch 1 oder 2, wobei das Protokollieren (140) des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens (130) der Fuzzing-Iteration Speichern: - eines Programmcode-Zählerwerts der Software bei dem mindestens einen Speicherzugriff; - eines Zeitstempels bei dem mindestens einen Speicherzugriff; - einer Charakteristik des mindestens einen Speicherzugriffs; und/oder - von Metadaten, die sich auf den mindestens einen Speicherzugriff beziehen; umfasst.
Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Protokollieren (140) des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens (130) der Fuzzing-Iteration auf statischer Instrumentierung der Software und/oder auf dynamischer Instrumentierung des Hardware-Targets (10) basiert.
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Erhalten (150) von Softwareabdeckungsfeedback während des Ausführens (130) der Fuzzing-Iteration; optional, wobei das Protokollieren (140) des mindestens einen Speicherzugriffs auf den Inputbuffer während des Ausführens (130) der Fuzzing-Iteration Speichern des Softwareabdeckungsfeedbacks umfasst.
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Prüfen (160), während des Ausführens (130) der Fuzzing-Iteration, ob die Fuzzing-Iteration unerwartetes Verhalten zeigt; wobei der mindestens eine protokollierte (140) Speicherzugriff auf den Inputbuffer den letzten Speicherzugriff auf den Inputbuffer, bevor die Fuzzing-Iteration unerwartetes Verhalten zeigt, umfasst.
Computer-implementiertes Verfahren (200a) zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target (10), umfassend: - Generieren (210a) von vorläufigen Fuzzing-Eingangsdaten; - Auswählen (220a) mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren; - Auswählen (230a) mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets (10), wobei Ausführen (130) der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert; - Anwenden (240a) des mindestens einen Mutationsoperators auf die vorläufigen Fuzzing-Eingangsdaten, wobei Fuzzing-Eingangsdaten generiert (110) werden; wobei das Anwenden (240a) des mindestens einen Mutationsoperators auf die vorläufigen Fuzzing-Eingangsdaten derart erfolgt, dass nach Senden (241a) der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target (10), bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets (10) gespeichert werden, ein Speicherinhalt in dem mindestens einen Speicherort auf einem Ergebnis des mindestens einen Mutationsoperators basiert.
Computer-implementiertes Verfahren (200b) zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target (10), umfassend: - Generieren (210b) von vorläufigen Fuzzing-Eingangsdaten; - optional, Senden (211b) der vorläufigen Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target (10), wobei die vorläufigen Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets (10) gespeichert werden; - Auswählen (220b) mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren; - Auswählen (230b) mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets (10), wobei Ausführen (130) der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert; - Anwenden (240b) des mindestens einen Mutationsoperators auf einen Speicherinhalt in dem mindestens einen Speicherort, der zumindest auf einem Teil der vorläufigen Fuzzing-Eingangsdaten basiert, wobei Fuzzing-Eingangsdaten im Inputbuffer generiert (110) werden.
Computer-implementiertes Verfahren (200c) zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration einer Software auf einem Hardware-Target (10), umfassend: - Generieren (210c) von Eingangsdaten für ein Inputmodel und/oder für eine Input-Grammatik zum generationsbasierten Generieren von Fuzzing- Eingangsdaten; - Auswählen (220c) mindestens eines Mutationsoperators aus einer Vielzahl von Mutationsoperatoren; - Auswählen (230c) mindestens eines Speicherorts in einem Inputbuffer in einem Arbeitsspeicher des Hardware-Targets (10), wobei Ausführen (130) der Fuzzing-Iteration der Software auf einem Speicherinhalt des Inputbuffers basiert; - Anwenden (240c) des mindestens einen Mutationsoperators auf die Eingangsdaten, auf das Inputmodel und/oder auf die Input-Grammatik; - Generieren (250c) von Fuzzing-Eingangsdaten auf Basis des Inputmodels und/oder auf der Input-Grammatik sowie auf Basis der Eingangsdaten, wobei mindestens eines von Inputmodel, Input-Grammatik und Eingangsdaten durch Anwenden (240c) des mindestens einen Mutationsoperators mutiert worden ist; - optional, Senden (251c) der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target (10); wobei das Anwenden (240c) des mindestens einen Mutationsoperators auf die Eingangsdaten, auf das Inputmodel und/oder auf die Input-Grammatik derart erfolgt, dass nach Senden (251c) der Fuzzing-Eingangsdaten an die Software auf dem Hardware-Target (10), bei dem die Fuzzing-Eingangsdaten in dem Inputbuffer des Hardware-Targets (10) gespeichert werden, ein Speicherinhalt in dem mindestens einen Speicherort auf einem Ergebnis des mindestens einen Mutationsoperators basiert.
Verfahren (200a, 200b, 200c) nach einem der Ansprüche 7 bis 9, wobei das Auswählen (230a, 230b, 230c) des mindestens einen Speicherorts in dem Inputbuffer umfasst: Auswählen mindestens eines Speicherorts in dem Inputbuffer, der nach dem computer-implementierten Verfahren (100) zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target (10) nach einem der Ansprüche 1 bis 6 gespeichert worden ist.
Verfahren (200a, 200b) nach einem der Ansprüche 7, 8 und 10, wobei das Generieren (210a, 210b) der vorläufigen Fuzzing-Eingangsdaten mutations- und/oder generationenbasiert ist.
Computer-System, dafür ausgelegt: - das computer-implementierte Verfahren (100) zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target (10) nach einem der Ansprüche 1 bis 6; und/oder - das computer-implementierte Verfahren (200a, 200b, 200c) zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration der Software auf dem Hardware-Target (10) nach einem der Ansprüche 7 bis 11; auszuführen.
Computer-Programm, dafür ausgelegt: - das computer-implementierte Verfahren (100) zum Protokollieren der Speicherzugriffe auf den Inputbuffer während einer Fuzzing-Iteration der Software auf dem Hardware-Target (10) nach einem der Ansprüche 1 bis 6; und/oder - das computer-implementierte Verfahren (200a, 200b, 200c) zum speicherbenutzungsbasierten Generieren von Fuzzing-Eingangsdaten für eine Fuzzing-Iteration der Software auf dem Hardware-Target (10) nach einem der Ansprüche 7 bis 11; auszuführen.
Computer-lesbares Medium oder Signal, das das Computer-Programm nach Anspruch 13 speichert und/oder enthält.