Frage der Woche: Sicherheit und Zuverlässigkeit von Open Source-Software

In Zeiten der massenhaften staatlichen Überwachung kann man keiner Closed Source-Software trauen, insbesondere nicht, wenn sie aus den USA kommt! Das sagen die Unterstützer von Open Source-Softwarelösungen im Sicherheits- und Verschlüsselungsbereich und begründen das damit, dass es nur bei Open Source möglich sei, den Quellcode der Software einzusehen und so Fehler, Backdoors und andere potentielle Sicherheitslücken ausfindig zu machen, beziehungsweise zu eliminieren. Außerdem sei es nicht so leicht, Open Source-Projekte, vor allem von außerhalb der USA, zur Zusammenarbeit mit Geheimdiensten – also zum willentlichen Einbau von Backdoors für NSA & Co. – zu zwingen. In den letzten Wochen sind immer mehr Zweifel an der Richtigkeit dieser These aufgetaucht. Zwar kam es schon 2008 beim Debian-Projekt zu einer ernsthaften Sicherheitslücke, diese galt aber lange Zeit als Sonderfall. Damals wurde der Zufallszahlengenerator für SSH Schlüssel durch das Entfernen einer Codezeile signifikant geschwächt. Es dauerte zwei Jahre, bis dieser Fehler jemandem auffiel. Dieses Jahr wurde nun die OpenSSL-Sicherheitslücke “Heartbleed” bekannt. Auch diese war über einen langen Zeitraum vorhanden und wurde von niemandem wahrgenommen. Das ist auch kein Wunder, denn solche Probleme lassen sich relativ einfach in den Source Code einbauen, aber nur sehr schwer erkennen. Ist das Argument, dass Open Source eben wegen der Offenheit der Quellen sicherer sei, deswegen hinfällig? Kürzlich kam es schließlich zu einem Problem ganz anderer Art. Das Truecrypt-Projekt wurde eingestellt. Egal ob es nun daran lag, dass die anonymen Entwickler von außen unter Druck gesetzt wurden, oder ob sie einfach keine Lust mehr hatten, das gleiche kann jederzeit bei anderen Projekten auch passieren. Sind Open Source-Projekte, vor allem anonyme, deswegen nicht mehr vertrauenswürdig? Zu dieser Frage äußern sich AVG, SecurEnvoy, Barracuda und Bitdefender.

Yuval Ben-Itzhak, Chief Technology Officer bei AVG Technologies, sagt: “Der ‘Heartbleed Bug’ ist mehr als eine Sicherheitslücke zum Auslesen von Passwörtern. Der Medienrummel um den Bug hat auch das Vertrauen in Open-Source-Projekte erschüttert. Doch der Verzicht auf Open Source wäre falsch, der Rückschritt vorprogrammiert. Open Source ist genau so wenig fehlerfrei wie ein anderer Code. Nach meiner Erfahrung kommt auf 10.000 Zeilen Code mindestens eine Schwachstelle. Die Anwender müssen also eigene Kontrollen durchführen und gründliche Test- und Scan-Verfahren anwenden. Stehen keine Testmöglichkeiten zur Verfügung, so sollten sie sich ein Verfahren einrichten, das den Open Source Code vor Schäden absichert, bevor sie ein neues Projekt starten. Wenn sie Schwachstellen finden, sollten sie diese mit der Öffentlichkeit teilen. Auf diese Weise bekommen sie einerseits Feedback oder Hilfestellungen, andererseits schaffen sie so ein Bewusstsein bei anderen. Machen sich die Nutzer gegenseitig auf Probleme aufmerksam und versuchen diese gemeinsam als Community zu lösen, wird Open Source auch weiterhin erfolgreich sein. Dies hilft zudem dabei, den Missbrauch von Schwachstellen durch Kriminelle zu vereiteln. Falls die Benutzer selbst keine Schwachstellenanalysen durchführen können, dann müssen sie sich einen geeigneten Anbieter suchen. Außerdem sollten sie Produkte für automatische Code-Scans einsetzen, um häufige Fehler in der Codierung zu identifizieren und anschließend zu beheben – bevor sie das Produkt in den Markt einführen. Darüber hinaus ist es wichtig, sicher zu stellen, dass sie dabei sowohl statistische als auch dynamische Untersuchungsmethoden anwenden. Open Source wird als gängiges Instrument der IT-Branche in absehbarer Zeit nicht einfach vom Markt verschwinden. Deshalb müssen wir als IT-Branche wachsam bleiben und die Codes, die wir für unsere Produkte und Services nutzen, konsequent testen und scannen. Nur so können wir die Zukunft der Branche sichern.”

Andy Kemshall, Technical Director bei SecurEnvoy, fügt hinzu: “Kommerzielle Software-Entwickler legen größten Wert auf ihre Reputation und das Nutzungserlebnis. Hacks oder Backdoors schädigen den Ruf und damit den zukünftigen Umsatz. Daher sollten Entwickler Qualitätssicherungen und Penetrationstests durchführen sowie Support anbieten. Bei Open Source-Lösungen ist beides nicht gegeben. Das sollte jedem Verantwortlichen klar sein, der im Business-Umfeld auf diese Programme setzt.”

“Ich glaube nicht, dass die angedeutete Schwarz-Weiß-Sicht auf Produkte nordamerikanischer Herkunft die Realität beschreibt”, so Dr. Klaus Gheri, Vice President Network Security bei Barracuda Networks. “Es ist wahr, dass staatliche Einrichtungen Daten sammeln. Doch dies gilt überall. Kein Land, kein Netz ist davor sicher. Anwender müssen ihre Daten im Transit durch ausreichend sichere Kryptoverfahren bei der Übertragung schützen. Dazu leistet die Open Source Community einen unersetzlichen Beitrag. Sie setzt die mathematischen Verfahren der Verschlüsslung in Software um und macht sie für jeden Anwender verfügbar. Auch die meisten Hersteller integrieren diese Verfahren in ihre Produkte. Die Unabhängigkeit der Community ist dabei auch ihre Achillesferse: Viele Projekte werden nur von ganz wenigen aktiven Entwicklern gewartet. Die Peer-Review als wichtiges Element der Qualitätsprüfung findet oft nicht in der nötigen Tiefe statt, weil Zeit oder Spezialwissen fehlen. Das betrifft im besonderen Maße Spezialthemen, wie SSH und Heartbleed anschaulich zeigen: Da es sich hier um eine durchaus komplexe Materie handelt, springen Kodierungsfehler oder Unzulänglichkeiten der Umsetzung eines Algorithmus nicht sofort ins Auge. Die Folge können Sicherheitslücken sein, welche die ganze Netz-Infrastruktur betreffen. Doch eine andere Problematik ist nicht weniger bedenklich. Staatliche Einrichtungen haben in der Vergangenheit daran gearbeitet, Krypto-Standards und -Normen schon bei der Entwicklung gezielt zu schwächen. Denn die Verschlüsslung von Daten läuft den Interessen der Sicherheitsbehörden strikt zuwider. Verschiedene Institutionen betreiben deswegen eine sehr aufwendige und langfristige Form von Social Engineering, um sowohl im Open-Source-Bereich als auch bei geschlossenen Sourcen zu verhindern, dass sich unentschlüsselbare Methoden verbreiten. Hier ist das Open-Source-Prinzip im Vorteil, weil es überprüfbar ist und zumindest im Prinzip vor dieser Art von Einflussnahme schützt. Schlechte Codes werden durch die Community verbessert, gleich ob es nun absichtlich sabotierte oder unsauber gearbeitete Software ist. Doch das funktioniert in der Praxis nur, wenn genügend viele und ausreichend kompetente Augenpaare nach Schwächen suchen. Ohne ökonomischen Anreiz ist das aber unwahrscheinlich: Von Luft allein lebt der Mensch nicht, und jeder Programmierer muss sein eigenes Auskommen sichern. Der Weg zu besserer Kryptographie ist, Open Source auch wirtschaftlich auf gesunde Beine zu stellen. Dann entsteht ein starker Anreiz, die Peer-Review ernsthaft und nachhaltig auch für Spezialprodukte zu betreiben. Wenn die Wirtschaft Wege findet, Open Source in kommerzielle Produkte zu integrieren, könnte das viel zur Sicherheit beitragen. Das läuft der Philosophie der Hardliner zuwider, die den Open-Source-Gedanken in seiner Reinform vertreten. Was fehlt, ist pragmatisches Umdenken etwa beim Thema Lizenzierung. Denn die unangenehmen Realitäten organisierter Datenspionage sind nur durch eine Dosis Pragmatismus zu beantworten.”

“Die Auseinandersetzung Open Source gegen proprietäre Technologie ist in den letzten Jahren zum Streitthema geworden, da immer häufiger behauptet wird, dass durch die Möglichkeit des Zugriffs auf den Quellcode auch böswillige Dritte die Funktionsweise einer Anwendung oder Protokollimplementierung besser verstehen können und diese somit anfälliger für Angriffe werden”, meint Bogdan Botezatu, Senior E-Threat Analyst bei Bitdefender. “Was dabei nur wenige verstehen, ist, dass jede Zeile Open-Source-Code, die in einem Projekt zum Einsatz kommt, vor der Implementierung genauestens in einem Peer-Review-Verfahren geprüft wird. Zudem muss gut geschriebener Code nicht im Verborgenen bleiben, um Sicherheit zu bieten. Je mehr Augen auf ein Projekt gerichtet sind, desto einfacher wird die Prüfung und damit die Aufdeckung möglicher Schwachstellen, die sonst vielleicht übersehen worden wären. Das Problem ist jedoch, dass diese Teams chronisch unterfinanziert und überarbeitet sind. Fairerweise muss man bedenken, dass das OpenSSL-Projekt derzeit über nur acht aktive Entwickler verfügt. Diese enorme Verantwortung ist also auf viel zu wenige Schultern verteilt. Positiv muss jedoch bewertet werden, dass die Ereignisse der letzten Zeit die gesamte Branche in Aufruhr versetzt haben und so dazu beitragen können, dass Unternehmen in Zukunft in Code-Prüfungen investieren werden, die dann ihren Weg zurück in die Community finden.”

[subscribe2]