Ein Programmcode ist ein bisschen wie ein Dschungel: komplex aufgebaut, schwer von außen einzusehen, mit unzähligen möglichen Wegen, die man hindurch nehmen kann. Schwachstellen in einem solchen Code zu finden ist wie Tiere zwischen den Bäumen im Urwald zu suchen: Man weiß, dass sie da sind, aber man sieht sie nicht direkt. Tobias Scharnowski von der Ruhr-Universität Bochum entwickelt daher gemeinsam mit seinem Betreuer Thorsten Holz neue Methoden, um im Dschungel der Einsen und Nullen effizient Programmierfehler aufspüren zu können.
Vom smarten Kühlschrank bis zum Industriesystem
Die Forscher interessieren sich vor allem für eingebettete Systeme: „Wir versuchen, die Sicherheit von Computern zu erhöhen, von denen die meisten Menschen gar nicht wissen, dass sie überhaupt Computer sind“, erklärt Scharnowski. Ein eingebettetes System ist eine Kombination aus einer Hardware und einer Software, die einen speziellen Zweck innerhalb eines größeren Systems erfüllt – zum Beispiel im Auto die elektronische Steuerung der Sitze.
Eigentlich ist ein eingebettetes System ein Computer, der einem eng umgrenzten Zweck dient. Smarte Glühlampen, ans Internet angeschlossene Kühlschränke oder intelligente Thermostate sind Beispiele für die eingebetteten Systeme, die auf der Agenda der Systemsicherheitsforscher stehen. Diese Gegenstände enthalten elektronische Steuerungstechnik mit vielen Zeilen Programmcode, in die sich Fehler eingeschlichen haben können.
Es geht den IT-Experten aber nicht nur um Gegenstände aus dem Haushalt. Vor allem interessieren sie sich für Steuerungssysteme in der Industrie, zum Beispiel aus dem Bereich der kritischen Infrastrukturen wie der Energieversorgung. Sicherheitslücken könnten hier besonders dramatische Auswirkungen haben.
Fehlersuche mittels Fuzzing
Scharnowski und Holz nutzen das sogenannte Fuzzing, um Fehler im Programmcode aufzuspüren. Als Fuzzer bezeichnet man Algorithmen, die die zu testende Software mit zufälligen Inputs füttern und prüfen, ob sie die Anwendung damit zum Absturz bringen können. Solche Crashs weisen auf Programmierfehler hin. Immer wieder variiert der Fuzzer den Input, um Schritt für Schritt möglichst viele Programmbestandteile zu erkunden.
Für bestimmte Anwendungsbereiche ist das Fuzzing bereits etabliert, zum Beispiel, um Betriebssysteme wie Windows oder Linux zu testen. Eingebettete Systeme hingegen wurden noch nicht ausgiebig damit untersucht; denn sie bringen einige Herausforderungen mit sich: Bei ihnen ist die Software – die sogenannte Firmware – in eine Hardware eingebettet, mit der sie interagiert.
Über die Hardware und ihre Funktionsweise haben die Forscher aber in der Regel wenig Informationen. „Das ist wie eine Blackbox für uns“, sagt Thorsten Holz. Hinzu kommt, dass diese Blackbox in der Regel nicht besonders leistungsstark ist – oft haben die Systeme verhältnismäßig wenig Speicher und langsame Prozessoren. Ein Problem, wenn die Forscher das Fuzzing direkt im System durchführen wollen. Es würde viel zu lange dauern, alle möglichen Inputs durchzuprobieren und auf die Antwort des Systems zu warten.
