-
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 Randfä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.
-
JinSeok Oh, Sungyu Kim, Eunji Jeong, and Soo-Mook Moon, „Os-less dynamic binary instrumentation for embedded firmware“, in 2015 IEEE Symposium in LowPower and High-Speed Chips (COOL CHIPS XVIII), pages 1-3. IEEE, 2015 offenbaren eine dynamische Instrumentierung über Debugger und Haltepunkte, die auf Software-Interrupts basiert. Dabei wird aktiv der Binärcode (englisch: binary) der Software verändert und eine Instruktion durch eine Software-Interrupt-Instruktion ersetzt.
-
Offenbarung der Erfindung
-
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target, wobei das Hardware-Target mindestens ein Haltepunktregister aufweist und dafür ausgelegt ist, eine Ausführung der Software vor Ausführung einer Anweisung der Software anzuhalten, wenn die Anweisung bei der Ausführung der Software erreicht wird und eine Speicheradresse der Anweisung in dem mindestens einen Haltepunkteregister gesetzt ist. Das Verfahren umfasst Setzen eines ersten Haltepunkts vor einer ersten Anweisung der Software. Das Verfahren umfasst weiterhin Ausführen oder Fortsetzen einer Fuzzing-Iteration der Software. Das Verfahren umfasst weiterhin erstes Prüfen, ob der erste Haltepunkt beim Ausführen oder Fortsetzen der Fuzzing-Iteration erreicht wird. Das Verfahren umfasst weiterhin Speichern einer ersten Protokollinformation umfassend, dass die erste Anweisung in der Fuzzing-Iteration erreicht worden ist. Das Verfahren kann Löschen des ersten Haltepunkts, wenn das erste Prüfen positiv ausfällt, umfassen. Das Softwareabdeckungsfeedback beim Fuzzing der Software umfasst die erste Protokollinformation.
-
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-System, das dafür ausgelegt ist, das computer-implementierte Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
-
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
-
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-lesbares Medium oder Signal, das das Computer-Programm nach dem dritten allgemeinen Aspekt (oder einer Ausführungsform davon) speichert und/oder enthält.
-
Das in dieser Offenbarung vorgeschlagene Verfahren nach dem ersten Aspekt (oder einer Ausführungsform davon) ist auf die Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target gerichtet, insbesondere wenn die Software an sich oder auf dem Hardware-Target nicht statisch instrumentiert werden kann.
-
Für Computersysteme wie Desktop-Systeme (PC etc.) und insbesondere für Software die in Form eines Programmiercodes vorliegt (z.B. open source) ist die statische Instrumentierung eine bekannte Methode, um Softwareabdeckungsfeedback beim Ausführen der Software und insbesondere während einer Fuzzing-Iteration der Software zu erlangen.
-
Die statische Instrumentierung für das Fuzzing kann jedoch bei Software, die auf einem eingebetteten System (englisch: embedded system), das in einem technischen Kontext eingebunden ist, ausgeführt wird, aus den folgenden Gründen schwierig sein: Der für das Fuzzing erforderliche Fuzzer muss typischerweise (z.B. aus Mangel an Rechen- und/oder Speicherkapazität im eingebetteten System) auf einem anderen Rechner ausgeführt werden. Daraus ergibt sich, dass Softwareabdeckungsfeedback aus dem eingebetteten System erst zu dem Fuzzer (oder einem anderen Rechner) transferiert werden muss. Weiterhin muss typischerweise ein Gesamtsystem getestet werden, dass durchaus eine Vielzahl von Komponenten umfassen kann. Die Software für das Gesamtsystem kann Drittparteibibliotheken und Softwarekomponenten anderer Zulieferer und/oder Kunden aufweisen. Häufig werden solche Softwarekomponenten als Binärdateien (d.h. in kompilierter Form, auch: Binärcode) geliefert, die nicht oder nur mit Aufwand modifiziert werden können. Da solche Softwarekomponenten nicht mehr kompiliert werden, können sie nur mit Aufwand statisch instrumentiert werden. Dagegen kann Software (oder Softwarekomponenten davon), die als Programmiercode vorliegt, leicht beim Kompilieren statisch instrumentiert werden. Allerdings nimmt die Größe der Software in jedem Fall durch die statische Instrumentierung zu, so dass häufig aufgrund der typischerweise beschränkten Ressourcen die statisch instrumentierte Software nicht mehr in den Speicher des eingebetteten Systems passt. Dasselbe gilt für weitere Funktionalitäten, um die die Software für das Fuzzing erweitert werden kann.
-
In einer alternativen Herangehensweise kann die Software des eingebetteten Systems in einem Emulator wie z.B. QEMU ausgeführt werden. Hierbei kann die Transparenz und Konfigurierbarkeit des Emulators dazu genutzt werden, das Softwareabdeckungsfeedback während des Fuzzing bereitzustellen. Leider ist die Einrichtung eines solchen Emulators für ein spezifisches Hardware-Target mit einem enormen Arbeitsaufwand verbunden, da typischerweise die Funktionalität der Software des eingebetteten Systems auf der Verfügbarkeit externer Hardware-Komponenten wie Sensoren und/oder Aktuatoren basiert. Fehlen allerdings solche Hardware-Komponenten in dem Emulator, kann die Software nicht unter denen Bedingungen getestet werden, für die sie eigentlich konzipiert ist. In der Tat wird sich die Software in diesem Fall anders verhalten als im Kontext des für sie konzipierten technischen Systems. Das kann sich zum Beispiel darin äußern, dass die Software wahrscheinlich andere Pfade durchlaufen wird, die nur bedingt mit dem eigentlichen Einsatzzweck der Software zu tun haben. Der Einsatz eines Emulators zwecks Softwareabdeckungsfeedback beim Fuzzing ist somit weniger geeignet.
-
Wird ein Debugger mit dem eingebetteten System verbunden, können Haltepunkt-Anweisungen (über mindestens ein Hardware-Haltepunktregister) genutzt werden, um die Ausführung der Software im eingebetteten System an einer gezielten Position im Code anzuhalten. Allerdings wird man nicht durch beliebige Haltepunkte ein annährend komplettes Softwareabdeckungsfeedback erhalten können, da die Anzahl der gleichzeitig aktiven Haltepunkte normalerweise stark limitiert ist. Zum Beispiel ist ein ARM Cortex-MO Mikrokontroller für maximal vier gleichzeitig aktive Hardware-Haltepunkte ausgelegt.
-
Das in dieser Offenbarung vorgeschlagene Verfahren nach dem ersten Aspekt (oder einer Ausführungsform davon) eignet sich besonders für das Fuzzing auf einem Hardware-Target/eingebetteten System und im (typischen) Fall, dass die Anzahl der Haltepunkte stark limitiert ist. Wie bereits ausgeführt, kann die Software durch das Fuzzing auf dem (echten) Hardware-Target - im Gegensatz zum Emulator - realistischer und somit besser getestet werden. Für das Verfahren ist es ausreichend, wenn das Hardware-Target mindestens einen Haltepunkt zulässt. Ausgehend von einer Startanweisung, die zumeist spezifiziert ist, kann dank des in dieser Offenbarung vorgeschlagenen Verfahrens und insbesondere durch ein systematisches Abfahren von Anweisungen durch sukzessives und strategisches Setzen mindestens eines Haltepunkts ein abstrakter Syntaxbaum zumindest zu dem durch die Fuzzing-Iteration abgedeckten Teil der Software ermittelt und/oder erprobt werden. Hierbei können einzelne Schritte beim systematischen Abfahren als Rutschen (englisch: slide) bezeichnet werden. Durch das Umsetzen (oder Löschen und Neusetzen) des mindestens einen Haltepunkt ist sichergestellt, dass die maximale Anzahl von Haltepunkten zu keinem Zeitpunkt überschritten wird. Alternativ oder zusätzlich zum Rutschen kann der mindestens eine Haltepunkt sukzessiv derart eingestellt werden, dass Sprünge im Syntaxbaum in Fuzzing-Iterationen erprobt und/oder abgefahren werden können. Durch eine Kombination von Rutschen und Sprünge können sehr effiziente Suchstrategien selbst in unbekannter kompilierter Software (closed-source) implementiert werden und die Software erprobt werden. Tritt unerwartetes Verhalten während einer Fuzzing-Iteration auf, kann das Softwareabdeckungsfeedback dazu genutzt werden, die Software und insbesondere deren Sicherheit durch eine Software-Änderung zu verbessern. Dadurch kann weiterhin die Funktionalität und insbesondere die Sicherheit des durch die Software gesteuerten, geregelten und/oder überwachten eingebetteten Systems verbessert werden.
-
Ein im Stand der Technik (Oh et al., siehe oben) bekanntes Verfahren für die dynamische Instrumentierung über Debugger und Haltepunkte auf Basis von Software-Interrupts könnte im Lichte der vorliegenden Offenbarung ebenfalls zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target eingesetzt werden. Zum Beispiel kann das bereits beschriebene Ersetzen einer Instruktion durch eine Software-Interrupt-Instruktion mehrfach wiederholt werden und dadurch verschiedene Haltepunkte gesetzt werden. Dabei muss allerdings der Speicher bei jeder Wiederholung neu geschrieben werden. Bei den genutzten EEPROM/Flash Speichern in Mikrocontrollern führt das jedoch zu einem erheblichen Overhead. Die Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target via Software-Interrupts wird dadurch ineffizient oder gar impraktikabel. Stattdessen werden in dem in dieser Offenbarung vorgeschlagenen Verfahren Hardware-Haltepunkte (via das mindestens eine Hardware-Haltepunktregister) gesetzt. Vorteilhaft erweist sich dabei, dass Hardware-Haltepunkte ohne großen Overhead gesetzt werden können. Somit kann Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target effizient und somit schnell erlangt werden.
-
Das in dieser Offenbarung vorgeschlagene Verfahren ist weiterhin auch in Anwendungsfällen (z.B. zum Testen/Erproben existierender Produkte) geeignet, in denen die Software aus einem Nur-Lese-Speicher (englisch: ROM, read-only memory) des Hardware-Targets ausgeführt wird. In diesem Fall ist das Ersetzen von Anweisungen im Binärcode der Software durch Software-Interrupt-Instruktionen, wenn überhaupt, nur mit erheblichem Aufwand möglich.
-
Figurenliste
-
- 1a illustriert schematisch ein computer-implementiertes Verfahren zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target.
- 1b illustriert schematisch eine Fortsetzung des computer-implementierten Verfahrens zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target.
- 2 illustriert schematisch eine beispielhafte Ausführungsform des computer-implementierten Verfahrens zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target.
- 3a zeigt eine beispielhafte Breitensuche in einem abstrakten Syntaxbaum bei dynamischer Instrumentierung mit drei verfügbaren Haltepunktregistern.
- 3b zeigt eine beispielhafte Tiefensuche in einem abstrakten Syntaxbaum bei dynamischer Instrumentierung mit drei verfügbaren Haltepunktregistern.
-
Detaillierte Beschreibung
-
Das in dieser Offenbarung vorgeschlagene Verfahren 100 ermöglicht die Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target. Das Hardware-Target kann zum Beispiel eine elektronische Steuereinheit sein, wobei die Software dafür ausgelegt sein kann, die elektronische Steuereinheit zu steuern, regeln und/oder zu überwachen. Das in dieser Offenbarung vorgeschlagene Verfahren 100 kann sich besonders für den Fall eignen, in dem die Software nicht statisch für Fuzzing instrumentiert ist. Weiterhin kann die Software (ganz oder teilweise) closed-source sein. Stattdessen kann Softwareabdeckungsfeedback beim Fuzzing der Software über dynamische Instrumentierung erlangt werden.
-
Bei Bestehen einer Debugging-Verbindung zu dem Hardware-Target kann zum Beispiel wie folgt, und wie in 2 beispielhaft illustriert, Softwareabdeckungsfeedback beim Fuzzing und insbesondere während einer Fuzzing-Iteration erlangt werden:
- Zunächst kann vor dem Ausführen der Fuzzing-Iteration ein erster Haltepunkt vor eine Startanweisung (englisch: function to instrument) gesetzt werden. Diese Startanweisung kann dadurch gekennzeichnet sein, dass sie beim Ausführen der Software unabhängig von den Eingangsdaten und somit bei einer jeden Fuzzing-Iteration ausgeführt wird. Die Startanweisung kann zum Beispiel aus einer Spezifikation der Software (z.B. symbol file) und/oder durch einen Testingenieur identifiziert werden.
-
Sodann kann die Fuzzing-Iteration der Software auf Basis der Fuzzing-Eingangsdaten für die Fuzzing-Iteration ausgeführt werden. Wird der erste Haltepunkt beim Ausführen der Fuzzing-Iteration erreicht, kann er als erreicht markiert werden. Optional und insbesondere, wenn die maximale Anzahl der (Hardware-)Haltepunktregister stark limitiert ist, kann der erste Haltepunkt gelöscht werden.
-
Sodann kann mindestens ein zweiter Haltepunkt vor eine Anweisung zum Beispiel in den nächsten Zweigen eines abstrakten Syntaxbaums 10 (englisch: abstract syntax tree, AST) gesetzt werden. Wird wiederum der zweite Haltepunkt beim Ausführen der Fuzzing-Iteration erreicht, kann er als erreicht markiert werden. Optional und insbesondere, wenn die maximale Anzahl der Haltepunktregister stark limitiert ist, kann der zweite Haltepunkt gelöscht werden. Die Fuzzing-Eingangsdaten, die dazu geführt haben, dass der zweite Haltepunkt erreicht wurde, können gespeichert und mit der dazugehörigen Anweisung bzw. einem dazugehörigen Knoten in dem abstrakten Syntaxbaum 10 verknüpft werden. Durch sukzessives Umsetzen (oder Löschen und Neusetzen) mindestens eines Haltepunkts kann Softwareabdeckungsfeedback während der Ausführung der Fuzzing-Iteration erlangt werden. Das Softwareabdeckungsfeedback kann zum Beispiel einen Pfad in dem abstrakten Syntaxbaum 10 umfassen, wobei der Pfad eine Sequenz von Knoten des abstrakten Syntaxbaums 10 umfassen kann. Jeder Knoten des abstrakten Syntaxbaum 10 kann eine Anweisung der Software sein. Häufig ist der abstrakte Syntaxbaum 10 der (kompilierten, closed-source) Software allerdings nicht im Vorfeld bekannt. Dennoch kann er mit dem in dieser Offenbarung vorgeschlagenen Verfahren 100 während des Fuzzing zum Beispiel durch sukzessiv protokollierte bedingte Sprünge, die in Reichweite aktuell gesetzter Haltepunkte sind mit vertretbarem Aufwand konstruiert werden. Die Vorgehensweise dazu kann von dem Hardware-Target abhängen. Zum Beispiel können bedingte Verzweigungsanweisungen analysiert werden und dadurch deren jeweilige Kindknoten im abstrakten Syntaxbaum 10 erkannt werden. Alternativ oder zusätzlich kann ein Haltepunkt jeweils vor einer bedingten Verzweigungsanweisung gesetzt werden und sodann mindestens ein Kindknoten gesucht und gefunden werden.
-
Es kann durchaus vorkommen, dass ein gesetzter Haltepunkt beim Ausführen der Fuzzing-Iteration nicht erreicht wird. Es kann sogar vorkommen, dass ein gesetzter Haltepunkt beim Ausführen einer Vielzahl von Fuzzing-Iterationen nicht erreicht wird. Anhand eines vorbestimmten Kriteriums (z.B., wenn nach einer vorbestimmten Anzahl von Fuzzing-Iterationen der Haltepunkt nicht erreicht wird und/oder bei einer Zeitüberschreitung), kann der Haltepunkt als übersprungen markiert werden. Dieser oder ein neuer Haltepunkt kann dann vor einer Anweisung in einem Zweig (im abstrakten Syntaxbaum 10) in der Nähe gesetzt werden, die bisher weder als erreicht noch übersprungen markiert worden ist. Ein Zweig in der Nähe kann zum Beispiel als Zweig definiert werden, der einen Abstand von eins zu einem erreichten Knoten in dem abstrakten Syntaxbaum 10 hat. Im Falle, dass nur übersprungene Haltepunkte in der Nähe sind, kann auch ein übersprungener Haltepunkt ausgewählt werden, der auf neuen Fuzzing-Eingangsdaten vielleicht doch erreicht werden kann.
-
Es können verschiedene Strategien, die auf dem Hardware-Target verfügbaren Haltepunkte zu setzen, in dem Verfahren 100 zur Anwendung kommen. Weiterhin können verschiedene Strategien in dem Verfahren 100 kombiniert und/oder abgewechselt werden. Eine Strategie kann zum Beispiel umfassen, möglichst schnell mit den Haltepunkten in die Tiefe des abstrakten Syntaxbaums 10 vorzudringen. Eine solche Tiefensuche (englisch: deep-first search) ist anhand eines Beispiels in 3a dargestellt. Alternativ oder zusätzlich kann die Strategie umfassen, möglichst schnell mit den Haltepunkten in die Breite des abstrakten Syntaxbaums 10 vorzudringen. Eine solche Breitensuche (englisch: breadth-first search) ist anhand eines Beispiels in 3b dargestellt. Alternativ oder zusätzlich kann die Strategie eine probabilistische Suche umfassen. Alternativ oder zusätzlich kann die Strategie eine entropische Suche umfassen. Alternativ oder zusätzlich kann die Strategie eine angeleitete Suche umfassen. Alternativ oder zusätzlich kann die Strategie weitere Suchstrategien umfassen. Bei der entropischen Suche kann ein Zweig (und/oder ein Knoten) im abstrakten Syntaxbaum 10, der beim Fuzzing erreicht wird, mit einem jeweiligen Wert für Informationsgewinn (auch: Entropie) versehen werden. Die Strategie bei der entropischen Suche kann dann umfassen, durch den Fuzzer solche Fuzzing-Eingangsdaten zu generieren, die einen Gesamtinformationsgewinn maximieren. Somit können eher Zweige mit hohem Informationsgewinn bevorzugt werden. Dadurch werden weniger bereits erreichte Zweige entdeckt. Somit können neue Zweige effizienter entdeckt werden. Bei der angeleiteten Suche kann das Setzen des jeweiligen mindestens einen Haltepunkts auf einer Benutzereingabe basieren. Wenn zum Beispiel ein Nutzer, ein Programmierer und/oder ein Auditor der Software eine kritische Stelle in der Software oder im abstrakten Syntaxbaum 10 der Software kennen, kann ein solches Wissen über eine Benutzerschnittstelle genutzt werden, die Haltepunkte und/oder Fuzzing-Eingangsdaten derart zu wählen, dass die kritische Stelle bei mindestens einer Fuzzing-Iteration erreicht und somit eingehend getestet wird.
-
Offenbart wird ein computer-implementiertes Verfahren 100 zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing einer Software auf einem Hardware-Target, wobei das Hardware-Target mindestens ein Haltepunktregister aufweist und dafür ausgelegt ist, eine Ausführung der Software vor Ausführung einer Anweisung der Software anzuhalten, wenn die Anweisung bei der Ausführung der Software erreicht wird und eine Speicheradresse der Anweisung in dem mindestens einen Haltepunktregister gesetzt ist. Das mindestens eine Haltepunktregister kann ein Hardware-Haltepunktregister sein. Ein Hardware-Haltepunkt ist ein Haltepunkt, der via ein Hardware-Haltepunktregister gesetzt wird.
-
Das Verfahren 100, schematisch dargestellt in 1a, umfasst Setzen 120 eines ersten Haltepunkts vor einer ersten Anweisung der Software. Setzen 120 des ersten Haltepunkts vor der ersten Anweisung der Software kann Setzen einer Speicheradresse der ersten Anweisung in das mindestens eine Haltepunktregister umfassen.
-
Das Verfahren 100 kann Ausführen 130 einer Fuzzing-Iteration der Software (auf Basis von zur Fuzzing-Iteration dazugehörigen Fuzzing-Eingangsdaten) umfassen. Alternativ kann das Verfahren 100 Fortsetzen 131 einer (bereits teilweise ausgeführten aber angehaltenen) Fuzzing-Iteration der Software umfassen.
-
Das Verfahren 100 umfasst erstes Prüfen 140, ob der erste Haltepunkt beim Ausführen 130 oder Fortsetzen 131 der Fuzzing-Iteration erreicht wird. Der erste Haltepunkt wird dann erreicht, wenn ohne den ersten Haltepunkt die erste Anweisung bei Ausführung der Software auf Basis der Fuzzing-Eingangsdaten der Fuzzing-Iteration ausgeführt worden wäre.
-
Das Verfahren 100 umfasst Speichern 150 einer ersten Protokollinformation, wobei die Protokollinformation umfasst, dass die erste Anweisung in der Fuzzing-Iteration erreicht worden ist.
-
Das Verfahren 100 kann Löschen 151 des ersten Haltepunkts, wenn das erste Prüfen 140 positiv ausfällt, umfassen.
-
Das Softwareabdeckungsfeedback beim Fuzzing der Software umfasst die erste Protokollinformation. Die erste Protokollinformation kann zum Beispiel weiterhin die Fuzzing-Eingangsdaten der Fuzzing-Iteration umfassen.
-
Das Verfahren 100, schematisch dargestellt in 1b (Fortsetzung zu 1a), kann Setzen 160 eines zweiten Haltepunkts vor einer zweiten Anweisung der Software, wenn das erste Prüfen 140 positiv ausfällt, umfassen. Setzen 160 des zweiten Haltepunkts vor der zweiten Anweisung der Software kann Setzen einer Speicheradresse der zweiten Anweisung in das mindestens eine Haltepunktregister oder in ein weiteres Haltepunktregister umfassen.
-
Das Verfahren 100 kann Ausführen 170 der Fuzzing-Iteration der Software (auf Basis von zur Fuzzing-Iteration dazugehörigen Fuzzing-Eingangsdaten) umfassen. Alternativ kann das Verfahren 100 Fortsetzen 171 der (bereits teilweise ausgeführten aber angehaltenen) Fuzzing-Iteration der Software umfassen.
-
Das Verfahren 100 kann zweites Prüfen 180, ob der zweite Haltepunkt beim Ausführen 170 oder Fortsetzen 171 der Fuzzing-Iteration erreicht wird, umfassen. Der zweite Haltepunkt wird dann erreicht, wenn ohne den zweiten Haltepunkt die zweite Anweisung bei Ausführung der Software auf Basis der Fuzzing-Eingangsdaten der Fuzzing-Iteration ausgeführt worden wäre.
-
Das Verfahren 100 kann Speichern 190 einer zweiten Protokollinformation umfassen, wobei die zweite Protokollinformation umfasst, dass die zweite Anweisung in der Fuzzing-Iteration erreicht worden ist.
-
Das Verfahren 100 kann Löschen 191 des zweiten Haltepunkts, wenn das zweite Prüfen 180 positiv ausfällt, umfassen.
-
Das Softwareabdeckungsfeedback beim Fuzzing der Software kann die zweite Protokollinformation umfassen. Die zweite Protokollinformation kann zum Beispiel weiterhin die Fuzzing-Eingangsdaten der Fuzzing-Iteration umfassen.
-
Das Setzen 120, 160 von Haltepunkten kann via eine Debugging-Verbindung zum Hardware-Target erfolgen. Weiterhin kann das Ausführen 130, 170 und/oder Fortsetzen 131, 171 der Fuzzing-Iteration via die Debugging-Verbindung zum Hardware-Target erfolgen. Das Verfahren 100 kann, wie in 1a als optionaler Schritt dargestellt, Initialisieren 110 der Debugging-Verbindung zum Hardware-Target umfassen.
-
Die erste Anweisung der Software kann eine vorbestimmte Startfunktion (englisch: function to instrument) der Software ist. Eine solche Wahl kann dafür geeignet sein, das Fuzzing oder zumindest eine Fuzzing-Iteration des Fuzzing zu starten. Alternativ kann die erste Anweisung eine jede beliebige Anweisung der Software (zum Beispiel bei Wiederholen 199) sein.
-
Das Setzen 160 des zweiten Haltepunkts vor der zweiten Anweisung der Software kann Auswählen einer zweiten Anweisung der Software umfassen, die in einem abstrakten Syntaxbaum 10 der Software einen Elternknoten mit der ersten Anweisung der Software teilt. Ein solches Auswählen der zweiten Anweisung kann zum Beispiel bei einer Breitensuche im abstrakten Syntaxbaum 10 genutzt werden.
-
Alternativ oder zusätzlich kann das Setzen 160 des zweiten Haltepunkts vor der zweiten Anweisung der Software Auswählen einer zweiten Anweisung der Software umfassen, die in einem abstrakten Syntaxbaum 10 der Software in einem Kindknoten der ersten Anweisung der Software angeordnet ist. Ein solches Auswählen der zweiten Anweisung kann zum Beispiel bei einer Tiefensuche im abstrakten Syntaxbaum 10 genutzt werden.
-
Alternativ oder zusätzlich kann das Setzen 160 des zweiten Haltepunkts vor der zweiten Anweisung der Software Auswählen des in der Software nächsten bedingten Sprungs als die zweite Anweisung der Software umfassen. Ein bedingter Sprung kann ein Sprung zu einer Anweisung der Software sein, der erfolgt, wenn eine Bedingung erfüllt ist. Dadurch können effizient Verzweigungen im abstrakten Syntaxbaum 10 abgelaufen werden. Ein bedingter Sprung kann zum Beispiel auf einem Programmierkonstrukt im Programmiercode der Software wie if-then-else, if-elseif-...-else, switch case, while, for etc. basieren.
-
Weiterhin können Kindknoten zu einer Anweisung im abstrakten Syntaxbaum identifiziert werden. Dadurch kann selbst bei anfänglicher Unkenntnis des abstrakten Syntaxbaums 10 sukzessive der abstrakte Syntaxbaum 10 konstruiert werden.
-
Das Auswählen der zweiten Anweisung der Software kann auf einer vorbestimmten Suchstrategie basieren. Wie bereits dargelegt, kann die Suchstrategie eine Tiefensuche umfassen. Alternativ oder zusätzlich kann die Suchstrategie eine Breitensuche umfassen. Alternativ oder zusätzlich kann die Suchstrategie eine probabilistische Suche umfassen. Alternativ oder zusätzlich kann die Suchstrategie eine entropische Suche umfassen. Alternativ oder zusätzlich kann die Suchstrategie eine angeleitete Suche umfassen.
-
Das Verfahren 100 kann, wie in 1a als optionaler Schritt dargestellt, Speichern 152 einer ersten Protokollinformation umfassen, wobei die erste Protokollinformation umfasst, dass die erste Anweisung in der Fuzzing-Iteration nicht erreicht worden ist. Das Verfahren 100 kann Löschen 151 des ersten Haltepunkts, wenn das erste Prüfen 140 negativ verläuft, umfassen, wobei das erste Prüfen 140 negativ verläuft, wenn ein vorbestimmtes Kriterium erfüllt ist. Das vorbestimmte Kriterium kann zum Beispiel erfüllt sein, wenn der erste Haltepunkt nach einer vorbestimmten Zeitdauer oder bis zum Ende der Fuzzing-Iteration nicht erreicht wird.
-
Das Verfahren 100 kann, wie in 1b als optionaler Schritt dargestellt, Speichern 192 einer zweiten Protokollinformation umfassen, wobei die zweite Protokollinformation umfasst, dass die zweite Anweisung in der Fuzzing-Iteration nicht erreicht worden ist. Das Verfahren 100 kann Löschen 191 des zweiten Haltepunkts, wenn das zweite Prüfen 180 negativ verläuft, umfassen, wobei das zweite Prüfen 180 negativ verläuft, wenn ein/das vorbestimmte Kriterium erfüllt ist. Das vorbestimmte Kriterium kann zum Beispiel erfüllt sein, wenn der zweite Haltepunkt nach einer vorbestimmten Zeitdauer oder bis zum Ende der Fuzzing-Iteration nicht erreicht wird.
-
Das Softwareabdeckungsfeedback beim Fuzzing der Software kann die erste und/oder zweite Protokollinformation umfassen. Die erste und/oder zweite Protokollinformation kann weiterhin zum Beispiel die Fuzzing-Eingangsdaten umfassen.
-
Das Verfahren 100 kann Wiederholen 199 des Verfahrens 100 umfassen. Zum Beispiel kann das Verfahren 100 so lange wiederholt 199 werden, bis die Ausführung der Fuzzing-Iteration und/oder das Fuzzing beendet ist. Durch das Wiederholen 199 können sukzessive Haltepunkte gesetzt und somit Softwareabdeckungsfeedback beim Fuzzing erlangt werden. Das Wiederholen 199 kann mit einem erneuten Schritt 110 beginnen. Alternativ oder zusätzlich kann das Wiederholen 199 mit einem erneuten Schritt 160 beginnen, wobei jede Durchnummerierung von Haltepunkten, Anweisungen etc. ums eins inkrementiert werden. Der erneute Schritt 160 kann somit lauten: Setzen eines dritten Haltepunkts vor einer dritten Anweisung der Software, wenn das zweite Prüfen positiv ausfällt, etc.
-
Offenbart wird weiterhin ein Computer-System, dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target auszuführen. Das Computer-System kann einen Prozessor und/oder einen Arbeitsspeicher umfassen. Das Computer-System kann dafür ausgelegt sein, über die Debugging-Verbindung mit dem Hardware-Target zu kommunizieren. Das Computer-System kann den Fuzzer umfassen, der dafür ausgelegt ist Fuzzing-Eingangsdaten für mindestens eine Fuzzing-Iteration der Software auf dem Hardware-Target zu generieren und bereitzustellen.
-
Offenbart wird weiterhin ein Computer-Programm, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zur Erlangung von Softwareabdeckungsfeedback beim Fuzzing der Software auf dem Hardware-Target auszuführen. Das 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.
