© otnaydur, 123RF

Anwendungsentwickler holen sich aus dem Web zahllose Open-Source-Komponenten, darunter leider auch solche, die bekannte Sicherheitsprobleme haben. Daraus entsteht dann ein gefährliches neues Gemisch. Heartbleed lässt grüßen

Wird Code von genügend vielen Augen geprüft, lassen sich dadurch alle Bugs ausmerzen, das hat Eric S. Raymond in seinem Aufsatz “The Cathedral and the Bazaar” [1] als Linus Law aufgeschrieben. Der Grundsatz, dass bei ausreichender Prüfung durch eine Vielzahl von Testern und Entwicklern die Fehlersuche effektiver ist als in der geschlossenen Software-Entwicklung, steht außer Zweifel. Problematisch wird aber die Situation, wenn die einst vieläugig geprüfte Software in die Jahre kommt, es neue Sicherheitslücken und Angriffskonzepte gibt und wenn Komponenten ungepatcht bleiben oder neue Versionen erscheinen.

Saure Milch

Das als Hüterin des Central Repository und als Anbieter von Supply Chain Management bekannte Unternehmen Sonatype hat vor einigen Monaten eine Art Brandrede zur Anwendungssicherheit schreiben lassen. Unter dem Titel “Don’t Drink Sour Milk, and other Avoidable Risks in the New World of Application Security” [2] bescheinigen die Autoren der derzeit betriebenen Anwendungsentwicklung ein fatales Baukastenprinzip. 90 Prozent einer typischen Anwendung bestehen laut Sonatype aus einer Art Kompilation von Open-Source-Komponenten, die zusammengesteckt seien wie Lego-Steine. Es herrsche inzwischen das Prinzip, Quellcode durch fertige Komponenten zu ersetzen.

Schnelle Zyklen

Es sei bei den vorherrschenden schnellen Releasezyklen klar, dass die unzähligen Komponenten bei der Security nicht mithalten könnten, analysiert Sonatype. Software sei, daher die Anspielung auf saure Milch im Titel des Vortrags, dem Alterungsprozess von Milch unterworfen, sie würde in Hinsicht auf ihre Sicherheit schlicht sauer. Dabei handle es sich nicht um ein Open-Source-Problem, stellt das Unternehmen klar, im Gegenteil: Open-Source-Software stehe essenziell für innovative Produkte und neue Services. Nur das blinde Vertrauen in Open Source sei problematisch. Linus Law mit dem Vielaugenprinzip stoße an technische Grenzen, so Sonatype.

Zahlenspiele

Die hauseigene Risiko-Analyse für über 1500 Applikationen habe ergeben, dass 71 Prozent ein kritisches oder zumindest ernstes Sicherheitsproblem in den darin verwendeten Open-Source-Komponenten aufweisen. Die Open Source Development Survey 2014 von Sonatype habe gezeigt, dass 31 Prozent der rund 3500 Befragten Unternehmen Verwundbarkeiten in den eingesetzten OS-Komponenten zu beklagen hatten. Sonatype empfiehlt, für einen Supply-Chain-Anbieter nicht unbedingt verwunderlich, als Abhilfe die Einführung eines eben solchen Systems, das die an der Entwicklung beteiligten Komponenten prüft.

Die Betreiber des Central Repository legen Zahlen nach. Es habe 2013 rund 58,1 Millionen Downloads von Komponenten aus den Archiven gegeben, die bekannte Sicherheitslücken aufweisen. Sonatype nennt dabei etwa alte Versionen der Programmierschnittstellen Bounty Castle Crypto [3] und Apache Struts [4]. Und dies, obwohl es davon jeweils neuere Versionen teils schon seit Jahren gegeben habe. Darin sei ein Versagen der Entwickler oder zumindest die fehlende Prüfung auf gepatchte Versionen zu sehen.

Im State of the Software Supply Chain Report 2015 [5] kommt Sonatype zu einem beunruhigenden Ergebnis. Die Downloads seien um rund 31 Prozent angestiegen und rund 6,2 Prozent davon hätten eine bekannte Sicherheitslücke enthalten. Der Zahl der Downloads von verwundbaren Komponenten sei um rund 94 Prozent gestiegen.

Heartbleed und die Folgen

Der Heartbleed-Bug in Open SSL hat die Diskussion um die Sicherheit von OS-Software Fahrt aufnehmen lassen. Seit 2012 schlummerte die Lücke nach einer kleinen Anpassung im Open-SSL-Protokoll unbemerkt. Kritiker bemängelten die Infrastruktur von Open-Source-Projekten, deren mangelnde finanzielle Ausstattung die notwendige Zahl fest angestellter Entwickler nicht hergebe.

Steve Marquess, Mitbegründer von Open SSL konterte in einem Blogpost [6], seine Bibliothek sei bei vielen multinationalen Konzernen und bei Regierungen im Einsatz, die über stattliche Ressourcen verfügen. Dennoch habe niemand den Fehler gefunden, auch Google habe zwei Jahre gebraucht, um ihn zu entdecken.

Die Linux Foundation reagierte, gründete die Core Infrastructure Initiative [7] und warb finanzkräftige Teilnehmer aus dem Kreis der amerikanischen IT-Konzerne. Intel, Cisco, IBM, Dell, Google, Amazon, Facebook und einige mehr verpflichteten sich zu jährlichen Zahlungen im mindestens sechsstelligen Bereich.

Das bei der Initiative angesiedelte Census-Projekt [8] versucht ein Ranking von Kernkomponenten aufzustellen, denen ausführliche Tests zukommen sollten. Aus verschiedenen Parametern entsteht ein Gefahrenindex (Abbildung 1). Das FTP-Protokoll steht ebenfalls unter den vom Census mit einem Risikofaktor von 11 versehenen Projekten.

Abbildung 1: Die Top Ten der risikobehafteten Kernkomponenten nach Analyse des Census-Projekts.

Sichtbarkeit

Die Heartbleed-Causa lässt den Open-Source-Apologeten Eric S. Raymond kalt. Er müsse ständig daran erinnern, dass nur Bugs sichtbar seien, deren Quellcode sichtbar sei, schreibt er in einem Beitrag [9]. Das führe dazu, dass die in Open-Source-Software gefundenen Fehler überbewertet werden, nur weil sie eben sichtbar seien, während die in Closed Source steckenden Risiken unterbewertet bleiben. Und dies obwohl in Closed Source mit hoher Wahrscheinlichkeit genauso schlimme oder schlimmere Bugs schlummern. Ihn würde brennend interessieren, welche Bug-Historie in den proprietären SSL-/TLT-Blobs stecke.