Ausgedruckt und gebunden würde er eine Bibliothek mit rund 30.000 Büchern füllen: der Code der Software, der in einem Neuwagen steckt, umfasst mehrere hundert Millionen Zeilen. Ihn en détail zu überprüfen, um mögliche Fehler oder Sicherheitslücken zu finden, ist selbst mit IT-Unterstützung ein Analysemarathon.  Code ist nicht geschrieben, um linear gelesen zu werden, sondern gespickt mit einer Vielfalt an komplexen Datenstrukturen und Querverweisen. Hier etwas zu übersehen, ist sehr wahrscheinlich. Der Einsatz von speziellen Tools zur Überprüfung von Code ist also unabdingbar. Standard dabei sind Analysewerkzeuge, die nach einer von zwei grundlegenden Methoden vorgehen, um Fehler aufzuspüren: Sie nutzen entweder statische Softwareanalysen oder dynamische Tests: Statistische Softwareanalysen untersuchen den Code anhand formaler Prüfungen nach typischen Programmierfehlern ab, ohne das Programm selbst auszuführen. Demgegenüber überprüfen dynamische Tests das Verhalten der Software während ihrer Ausführung.

»Zu beiden Prüfmethoden forschen Security-Expert*innen unter anderem an den Fraunhofer-Instituten für Angewandte und Integrierte Sicherheit AISEC, für Kommunikation, Informationsverarbeitung und Ergonomie FKIE, für Offene Kommunikationssysteme FOKUS und bei uns. Die Forschungsteams haben verschiedene Testroutinen und Tools entwickelt und sind damit in der Lage, eine Vielzahl von Schwachstellen in Code zu identifizieren«, erklärt Matthias Meyer vom Fraunhofer-Institut für Entwurfstechnik Mechatronik IEM. Trotzdem, so betont der Forscher, bleiben einzelne Programmfehler häufig so lange unentdeckt, bis Mängel in der Software offensichtlich werden oder Cyberkriminelle sie als Einfallstor nutzen, um Programmabläufe zu manipulieren«. Und dies gelte nicht nur für die Schwachstellenanalysen der Teams an den Fraunhofer-Instituten, sondern sei die unbefriedigende Situation, die Security-Expert*innen weltweit betrifft. Denn bei allen Sucherfolgen der Tools und trotz aller Fortschritte bei der Weiterentwicklung der Prüfverfahren, haben die Einsatzbedingungen der Testwerkzeuge bislang noch spezifische Schwächen, die sowohl ein umfassendes Testen von Software als auch die Bewertung der Prüfergebnisse erschweren.

Status quo der Testhürden

»Statische Analysen haben eine Stärke, die sie unverzichtbar macht: Sie durchforsten den Softwarecode auch umfassender und komplexer Programmstrukturen so, dass alle potentiell möglichen Programmabläufe betrachtet werden«, so Meyer. Geprüft wird dabei zum Beispiel, ob die Bereichsgrenzen für Speicherzugriffe zu großzügig bemessen wurden und dadurch mehr Informationen freigeben als vorgesehen. Derartige und viele weitere Arten an Fehlern oder Versehen in der Programmierung finden die Codeanalysen zu einem sehr hohen Prozentsatz. »Aber leider führt die zuvor genannte Stärke auch zu einer Schwäche: Das Betrachten aller möglichen Programmausführungen erfordert Abschätzungen, die zu Ungenauigkeiten und falschen Warnungen führen können. Das heißt längst nicht alle gemeldeten Funde können zur Laufzeit wirklich zum Problem werden und müssen behoben werden. «, betont Meyer. Denn die Liste der Fundstellen umfasst auch viele Einträge, die von dem Programm überhaupt nicht benutzt werden oder sie umfasst Wertebereiche, die bei den Berechnungen, die tatsächlich durchgeführt werden, nicht vorkommen können. »Der große Nachteil der statischen Prüfung aber ist, dass sie solche Zusammenhänge nicht feststellen kann«, sagt Meyer. Die Analyse des Codes allein könne nicht überprüfen, ob die als kritisch eingestuften Funde während der Ausführung der Software überhaupt relevant sind. Um das tatsächliche Gefahrenpotenzial zu bewerten wären vielmehr zusätzlich Erkenntnisse aus der Ausführung der Software notwendig.

Dies ist die Domäne der dynamischen Test-Methoden. Eine davon nennt sich »Fuzzing«. Bei diesem Verfahren durchläuft die Software verschiedene Belastungstests, die durch zufällig generierte Daten erzeugt werden. Es werden also verschiedenste Variationen von Eingabeparametern und Prozessszenarien getestet, um Programmkonstellationen zu identifizieren, die zu einem Programmabsturz führen oder Datenmissbrauch ermöglichen. »Allerdings hat auch Fuzzing einen gewichtigen Nachteil: Die Anzahl der möglichen Eingaben ist riesig. Es sind also sehr viele dieser zufällig generierten Testszenarien nötig, wenn möglichst viele Schwachstellen gefunden werden sollen«, erklärt Meyer.

Was erschwerend hinzukomme: Bei beiden Testmethoden erfordert die Vorbereitung und die Durchführung der Codeanalysen sowie die Bewertung der Funde spezifisches Know-how und Handarbeit der Spezialist*innen. Zudem genüge es nicht, ein Programm einmalig zu prüfen. Es muss regelmäßig und vor allem nach Veränderungen oder Erweiterungen beispielsweise durch Updates neu durchgecheckt werden. »Bis dato ist Security-Testing in zweifacher Hinsicht unzureichend: Zum einen reichen Humanpower und Zeit der Security-Teams schlicht nicht aus, um sämtliche Software in ihrem jeweils aktuellen Status quo zu überprüfen und zum anderen bleiben selbst in den Fällen, wo sie das tun, die Schwachstellen oft unerkannt«, resümiert Meyer. Diese Situation ändern soll nun ein im Rahmen des Forschungsvorhabens »IntelliSecTest« entwickeltes neuartiges Testwerkzeug.

Security-Testing effizienter und einfacher machen

In dem vom Fraunhofer-Programm PREPARE geförderten Projekt bündeln die vier Fraunhofer-Institute ihre Erfahrungen, um ihre Tools auf einer gemeinsamen Plattform in eine hybride Testumgebung zu integrieren. Die Idee dabei: Beide Testmethoden werden in aufeinander aufbauenden Analyseschritten so miteinander verzahnt, dass ein durchgängig automatisierter Testprozess entsteht, bei dem die einzelnen Verfahren die Schwächen der jeweils anderen ausgleichen.

Als zentrales Ergebnis haben die Forscher*innen nun aber eine neuartige Plattform entwickelt, die die Prüfarbeit der verschiedenen Tools koordiniert, steuert und bewertet. Wird eine Prüfung gestartet, durchläuft die Software auch bei IntelliSecTest zunächst eine statische Analyse. Auf Basis der erzielten Ergebnisse berechnet das System dann Testfälle für das Fuzzing. Die Belastungstests arbeiten also nicht mehr aufgrund zufällig generierter Daten »drauf los«, sondern testen gezielt die Softwareteile, in denen aufgrund der vorangegangenen statischen Analysen eine Sicherheitslücke wahrscheinlich ist. Mit den Erkenntnissen aus diesen dynamischen Tests kann das System nun einwandfrei feststellen, welche Schwachstellentreffer tatsächlich eine Gefährdung darstellen und in Kombination mit dem Wissen aus der statischen Codeanalyse den Nutzer*innen dazu detaillierte Angaben zu Art und der exakten Position im Code anzeigen.

IntelliSecTest ist spezialisiert auf die Programmiersprachen C und C++, die vom eingebetteten System bis zur komplexen Anlagensteuerung vielfältig verwendet werden. Unter anderem deshalb, weil sie ein sehr hohes Maß an Kontrolle über die Performance und den Ressourcenverbrauch bieten, zum Beispiel durch manuelles Speichermanagement. »In diesem Bereich liegt aber gleichzeitig auch eine der häufigsten Ursachen für kritische Fehler, die bei der Entwicklung entstehen können«, betont Meyer.

Die Durchführung und Auswertung der Tests erfolgt automatisiert und lässt sich über die Benutzeroberfläche weitgehend intuitiv steuern. Zudem lässt sich das Testwerkzeug direkt in die gängigen Entwicklungsumgebungen einbinden und unterstützt insbesondere auch beim Re-Testing des Codes nach einer erfolgten Beseitigung einer Schwachstelle. »IntelliSecTest ermöglicht dadurch Programme erheblich einfacher, umfassender und frühzeitiger als bisher zu prüfen. Und das nicht mehr nur durch Spezialist*innen für IT-Security-Testing«, so Meyer. Vielmehr können mit IntelliSecTest nun die Teams in der Softwareentwicklung ihre Programme auch selbst überprüfen.

(stw)