Was Analyse-Tools entgeht Schwachstellen in Open Source Code aufspüren

Statische und dynamische Code-Analyse-Tools helfen dabei, allgemeine Programmierfehler und damit potenzielle Schwachstellen zu identifizieren. In Open Source-Komponenten finden sich aber alltägliche Bugs, die sich auf diese Weise nicht so einfach aufspüren lassen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

Unternehmen sind in erster Linie an der Sicherheit ihrer Software interessiert. Begriffe und Kategorien wie statische Analyse, dynamische Analyse, Penetrationstest und Schwachstellenanalyse sind eher verwirrend. Hier ein Überblick der gängigsten Sicherheitstests und ihre wichtigsten Merkmale:

Statische Analyse

Statische Analyse-Tools analysieren den Source Code oder kompilierte Applikationen, um Schwachstellen, im von internen Entwicklern geschriebenen Code, aufzudecken. Dazu erstellen sie entweder einen abstrakten Syntaxbaum (AST) oder ein Modell der Anwendung, das beispielsweise Ablaufsteuerung, Datenfluss oder Variablen abbildet. Ist der AST einmal fertiggestellt, kann er anhand vordefinierter Regeln abgefragt werden und so allgemeine Sicherheitsprobleme aufspüren.

Die meisten statischen Tests können nur in vollständigen Anwendungen und unter Berücksichtigung aller Abhängigkeiten eine Analyse durchführen. Deshalb und aufgrund ihrer Komplexität werden statische Tests erst gegen Ende des Entwicklungsprozess angewandt.

Tools zur statischen Analyse eignen sich gut, um die häufigsten Schwachstellen wie SQL-Injections, Cross-Site-Scripting und Pufferüberlauf zu identifizieren. Handelt es sich allerdings um Themen wie Authentifizierung oder die Ausweitung von Rechten, sind sie nur bedingt geeignet.

Dynamische Analyse

Anders als beim statischen Test prüft die dynamische Analyse eine Applikation während ihrer Laufzeit. Dynamische Analyse-Tools können eine Applikation erkennen und traversieren, um Eingabeschnittstellen für das sogenannte Fuzzing zu identifizieren.

Fuzz-Testing wird in Software-Entwicklungs-Projekten normalerweise im Rahmen eines Black-Box-Tests durchgeführt. Dabei werden automatisch generierte, zufällige Daten über die Eingabeschnittstellen zur Verarbeitung eingespeist (z. B. Öffnen einer Datei, deren Datenformat das Programm unterstützt).

Verursacht das Programm daraufhin ein reproduzierbares Problem (z. B. Absturz), lassen sich Ursachen erforschen und Sicherheitslücken schließen. Beispiele hierfür sind SQL-Befehle, lange Strings, negative Zahlen und unerwartete Daten.

Dynamische Tools benötigen eine laufende Anwendung in einer Testumgebung, in der Regel in Kombination mit einer Datenbank für Datenabfragen. Sie kommen also erst sehr spät im Entwicklungsprozess zum Einsatz und sind vor allem nützlich, wenn es um die Identifizierung von Fehlern bei der Eingabevalidierung und um eine Speicherzuordnung geht. Da sie eine laufende Anwendung testen, ist es allerdings schwierig, sicherheitsrelevante Fehler bis zum Quellcode zurückzuverfolgen und zu beheben.

Schwachstellenanalyse

Tools zur Schwachstellenanalyse, auch als Penetrationstest bezeichnet, ähneln dynamischen Analyse-Tools. Auch sie kommen in laufenden Anwendungen zum Einsatz, suchen nach Sicherheitsrisiken und generieren zufällige, unerwartete Daten, um den späteren Einsatz zu simulieren.

Dazu verfügen Schwachstellenanalyse-Tools oftmals über Scripts oder Regeln, mit denen bekannte Sicherheitslücken ausgenutzt werden können. Diese Werkzeuge helfen den Entwicklern dabei, mögliche Angriffsmuster nachzubilden. Angewendet wird die Schwachstellenanalyse für gewöhnlich bei Produktionssystemen, um nicht gepatchte Netzwerkanwendungen, Betriebssysteme und Applikationen zu identifizieren.

Eine Universallösung, um alle verschiedenen Sicherheitsrisiken aufzudecken, gibt es nicht. Manche Bugs sind auf das Software-Design zurückzuführen, z. B. bei der Speicherung von Schlüsseln und Berechtigungen. Solche Schwachstellen lassen sich auch nicht von automatisierten Technologien aufspüren. Welche Lösung sich am besten eignet, hängt immer von der Art der Schwachstelle ab. Deswegen empfiehlt sich die Verwendung verschiedener Testmethoden, deren Auswahl sich sowohl an der Bedeutung der getesteten Anwendung als auch am Risikoprofil des Unternehmens ausrichtet.

Gängige Fehler in Open-Source-Komponenten

In Bezug auf Sicherheit bietet Open Source Software einige Vorteile. Sie kann kostenlos heruntergeladen, überprüft und verändert werden. Übliche Security-Bugs lassen sich oft in einer frühen Phase eines Projekts erkennen und beheben, ganz nach dem Motto: „Given enough eyeballs, all bugs are shallow“ (Je mehr Augen draufschauen, desto mehr Fehler werden entdeckt).

Dieser als Linus Law bekannte Ansatz hilft Fehler zu vermeiden, die zu einer falschen Eingabevalidierung oder zu anderen weit verbreiteten Problemen führen. Der grundsätzliche Gedanke dahinter: Da der Quellcode einer Komponente für jedermann frei zugänglich ist, sind die Codes umfassend geprüft und die meisten Sicherheitsprobleme bekannt.

Dennoch gibt es Sicherheitsrisiken, die ohne das Wissen und der Erfahrung eines Sicherheitsexperten nicht identifiziert werden können. Diese Bugs umfassen unter anderem zeitliches Fehlverhalten (race condition) und Logikfehler in Sicherheit-Subsystemen. Sie erfordern einen Experten, der den Source Code prüft, Theorien über potentielle Schwachstellen erstellt und deren Anfälligkeit durch Versuche beweist oder widerlegt.

Diese Art von Sicherheitsrisiken findet sich am häufigsten in Open Source-Projekten. Nutzen Entwickler ältere Code-Bibliotheken mit bereits bekannten Schwachstellen, nimmt das Risiko unerkannter Open Source Sicherheitslücken noch deutlich zu. Dieses Problem ist mittlerweile so weit verbreitet, dass das Open Web Application Security Project (OWASP) die „Nutzung von Komponenten mit bekannten Sicherheitslücken“ in die Top Ten-Liste der Schwachstellen in Webapplikationen aufgenommen hat.

Eine einfachere Lösung

Code-Analyse und die Ausführung von Sicherheitsregeln beanspruchen eine sehr hohe Speicher- und Rechenleistung. Wesentlich effektiver ist es, Open-Source-spezifische Richtlinien zu entwickeln und durchzusetzen.

Dazu muss ein Unternehmen zunächst festlegen, welche Aspekte einer Open-Source-Komponente wichtig sind. Steht Funktionalität an erster Stelle, folgen als weitere Kriterien z. B. bekannte Sicherheitsrisiken (bzw. Vorgeschichte von Schwachstellen), Programmiersprachen, Unterstützung der Open Source Community und die Komplexität des Codes.

Der nächste Schritt ist die Festlegungen und Einhaltung der Richtlinien. Tools, die den Source Code oder Binärprogramme scannen, vereinfachen diesen Prozess und verschaffen Unternehmen einen Überblick, welche Arten von Open Source wie häufig genutzt werden, und welche Risiken diese Nutzung birgt. Zudem bauen sie ein zentrales Verzeichnis sämtlicher verwendeter Open Source Software im Unternehmen auf.

Kontinuierliches Monitoring

Diese Sichtbarkeit von Open Source Software bietet sowohl kurz- als auch langfristige Vorteile. So werden die Komponenten sofort bei Identifizierung in eine Datenbank bekannter Sicherheitslücken aufgenommen – und zwar für jede Version sämtlicher Komponenten. Entwicklerteams werden frühzeitig auf entdeckte Schwachstellen aufmerksam gemacht und können in der Softwareentwicklung rechtzeitig Fehler beheben und Kosten einsparen.

Langfristig gesehen lassen sich Sicherheitsprobleme schneller beheben, da neue Schwachstellen permanent sichtbar bleiben und für Tests von internen Anwendungen genutzt werden können. In der Regel sind die Sicherheitstests mit dem Release einer Anwendung abgeschlossen.

Ein Open Source Monitoring Service hingegen stellt während der gesamten Laufzeit der Anwendung sicherheitsrelevante Informationen zur Verfügung. Ein zusätzlicher Scan oder eine Analyse ist nicht nötig. Findet sich in irgendeinem Open-Source-Projekt eine neue Schwachstelle, werden die betroffenen Unternehmen sofort informiert. Die unsicheren Komponenten lassen sich damit zu jeder Applikation im Unternehmen zurückverfolgen, in der sie verwendet werden.

Mike Pittenger

Open Source sorgt für eine schnellere Time-to-Market, höhere Sicherheit und ist sofort einsetzbar. Entscheidend ist ein Überblick aller genutzten Komponenten sowie deren Risiken in Bezug auf Lizenzierung, Sicherheit, und Betrieb. Dies gilt nicht nur am Anfang des Entwicklungsprozesses, sondern auch über die gesamte Lebensdauer der Anwendung hinweg.

* Mike Pittenger ist Vice President of Security Strategy bei Black Duck Software und seit über 30 Jahren erfolgreich in Technologieunternehmen tätig. Er blickt auf über 25 Jahre Erfahrung im Management sowie 15 Jahre Erfahrung im Bereich Security zurück. Bei Black Duck ist Pittenger verantwortlich für die strategische Führung der Security-Lösungen, u. a. in der Produktentwicklung und strategischen Partnerschaften.

(ID:44406013)