Die Sicherheit von Open-Source-Software ist ein häufig diskutierter Aspekt, wenn es um das Verhältnis von proprietärer und quelloffener Software geht. Insbesondere von Seiten der Open-Source-Gemeinde wird der Sicherheitsaspekt von Open-Source-Software gerne hervorgehoben. Wie immer in einer ideologisch geprägten Debatte wird es mit Begriffen, Szenarien und Argumenten nicht immer so genau genommen. Beim Thema Sicherheit werden viele Aspekte vermischt. Es geht um die grundsätzliche Sicherheit vor Schadprogrammen ebenso wie um den Schutz vor Überwachung und Datenabschöpfung.
Begriffsdefinition: Open Source bzw. quelloffen ist jede Software, deren Quellcode einsehbar ist. Es muss sich dabei nicht zwingend um Software unter einer freien Lizenz handeln, ist allerdings oft deckungsgleich. Proprietär bzw. geschlossen ist in diesem Kontext jede Software, die lediglich als binäre Software verteilt wird.
Welche Gefahren sollen abgewendet werden?
Sicherheit im wörtlichen Sinne, d.h. absolute Sicherheit vor Beeinträchtigungen jeglicher Art, ist ein Zustand, den man bei Software nie mit Sicherheit erreichen kann. Fehlerfreiheit bzw. die Abwesenheit von Sicherheitslücken ist ein Momentzustand – bis die nächste Sicherheitslücke bekannt wird und dann per Update beseitigt wird. Die Sicherheitsdebatte ist daher auch eine Frage des Umgangs mit Sicherheitslücken.
Grundsätzlich muss in einer Sicherheitsdebatte konkretisiert werden, welche Gefahren vermieden werden sollen. Grob vereinfacht können dies einige sein (ohne Anspruch auf Vollständigkeit)
- Gefahr durch staatliche Überwachung
- Gefahr durch Datenabfluss zu großen Unternehmen
- Gefahr durch Kriminalität
Dabei können die Risiken für verschiedene Anwender oder Anwendungsszenarien unterschiedlich gewichtet werden. Jeder dieser Punkte impliziert andere Aspekte. So ist es eher unwahrscheinlich, dass Software gezielt Schwachstellen für Kriminelle enthält, während Backdoors – also Hintertüren – ein allgegenwärtiges Thema für Geheimdienste und Sicherheitsbehörden sind, unabhängig davon, ob sie bereits existieren oder nicht. Die Gefahr des Datenabflusses muss nicht einmal durch eine Sicherheitslücke entstehen, sondern kann durch die Funktionsweise einer Software bedingt sein. Gerade Cloud-Dienste verleiten den Nutzer offenbar dazu, seine Daten aus dem heimischen Betriebssystem ins Netz zu stellen. Solche Herstellerdienste sind in modernen Betriebssystemen oft fest implementiert.
Der Sicherheitsvergleich zwischen Open Source und proprietärer Software wird allzu oft auf den Vergleich Linux vs. Windows reduziert. Windows war lange Zeit das proprietäre Konzernprodukt schlechthin und Linux stand für Offenheit. Die chronischen Sicherheitsprobleme von Windows haben aber nicht nur mit der proprietären Software zu tun und der gute Ruf von Linux ist nicht nur auf den quelloffenen Code zurückzuführen. Die Vor- und Nachteile beider Systeme dürfen daher nicht zu einer Verurteilung der Entwicklungsmodelle führen.
Umgang mit Sicherheitslücken
Transparenz und Planbarkeit
Es gibt objektive Unterschiede zwischen den Systemen im Umgang mit Sicherheitslücken. Die meisten Firmen hinter proprietärer Software pflegen keine öffentliche Liste an Sicherheitsmängeln oder Fehlern. Es ist also vollkommen unklar, wie viele Sicherheitsprobleme den Firmen bekannt sind und welche Korrekturen eigentlich schon vorliegen und an den Anwender verteilt werden könnten. Der Benutzer bekommt lediglich bei den Aktualisierungen mit, dass Fehler existierten und geschlossen wurden.
Hinzu kommt die Tatsache, dass viele proprietäre Softwareprojekte festgelegte Zyklen für die Veröffentlichung von Fehlerbehebungen haben. So genannte „Patch Days“. Dies trifft z. B. für Adobe, Microsoft und Oracle zu. Andere Firmen wie Apple haben zumindest relativ fixe Release Termine (im Fall Apple meist Dienstagnachmittag). Das heißt im Umkehrschluss aber auch, dass selbst bekannt gewordene Sicherheitslücken im schlimmsten Fall mehrere Wochen offen bleiben.
Die meisten Open Source Projekte pflegen dagegen einen relativ transparenten Umgang mit Sicherheitslücken und Fehlern. Öffentliche Plattformen für Fehlerberichte sind obligatorisch und manche Projekte wie Debian pflegen auch eine Liste der bekannten Sicherheitsmängel in der Linux-Distribution.
Security through Obscurity?
Der Satz stammt eigentlich aus dem Netzwerkbereich, wird aber heute oft auch auf proprietäre, geschlossene Software angewendet. So wird argumentiert, dass die Nichtfreigabe des Quellcodes Kriminelle daran hindert, Sicherheitslücken zu finden. Windows ist jedoch das beste Beispiel dafür, dass man den Quellcode nicht braucht, um Sicherheitslücken zu finden.
Befürworter von Open Source betonen hingegen, dass der frei zugängliche Quellcode es vielen verschiedenen Personen ermöglicht, diesen zu prüfen und Sicherheitslücken zu finden und zu melden. Dadurch sei die Software sicherer als geschlossene Projekte, bei denen Sicherheitslücken jahrelang unbemerkt bleiben können – selbst wenn die Firma dahinter davon weiß. Damit sind wir wieder beim Umgang mit Sicherheitslücken.
Wer suchet, der findet
Wichtig ist nicht nur Einsicht in den Code, sondern auch Programme und Personen die Suchen. Dabei spielen monetäre Anzeige eine Rolle, damit Sicherheitslücken an die Firmen und nicht an Kriminelle gemeldet werden. Diese Bug-Bounty-Programme setzen finanzielle Anreize für Personen, die Lücken finden und an das Unternehmen melden. Beides ist nicht unbedingt an das Entwicklungsmodell gekoppelt, spielt aber bei proprietärer Software eine größere Rolle.
Der niedrigschwellige Einblick in den Quellcode als Sicherheitsvorteil bei Open-Source-Programmen setzt voraus, dass dies auch genutzt wird. Allerdings gibt es viele Open Source-Projekte mit einer sehr dünnen Personaldecke. Teilweise entwickelt ein sehr kleiner Kreis von Personen (manchmal auch nur eine Person) über Jahre hinweg an einem Projekt. Es gibt hier also eine sehr beschränkte Anzahl Augen, die den Code wirklich kennt und versteht. Das betrifft nicht nur irgendwelche Nischenprojekte mit eher geringen Relevanz, sondern auch große und zentrale Bestandteile der Open Source-Welt mit vielen Firmen als Anwendern.
Vor- und Nachteile im Verhältnis zu den Bedrohungsszenarien
Wenn es um Sicherheit geht muss man den Aspekt immer in Relation zu den erwarteten Bedrohungen setzen. Die folgende Auflistung bietet ein paar Anhaltspunkte.
Bedrohungsszenario staatliche Überwachung
Ziel staatlicher Überwachung ist es, Zugang zu Systemen zu erhalten. Für ein Unternehmen ist es einfacher, eine Hintertür in proprietäre Software einzubauen, da der Quellcode für Außenstehende nicht einsehbar ist und das dahinter stehende Unternehmen gesetzlich dazu verpflichtet wäre, dies zu tun und zudem Stillschweigen zu bewahren. Dies setzt allerdings einen Firmensitz im jeweiligen Land voraus. Die Folgen in Form von Datenlecks können wiederum von Sicherheitsexperten erkannt werden.
Aber auch Open-Source-Unternehmen können dazu gezwungen werden. Viele Projekte verfügen bisher nicht über Strukturen für Reproducible Builds. Die ausgelieferten Binärdaten können daher vom Quellcode abweichen.
Es wäre aber auch langfristig und mit viel Aufwand möglich, Lücken in Open-Source-Projekte einzuschleusen. Staatliche Akteure verfügen zweifellos über ausreichende Ressourcen und zeitliche Perspektiven.
Bedrohungsszenario Datenabfluss
Der Datenabfluss ist jederzeit messbar. Er findet also nicht unbemerkt statt. Allerdings ist nicht immer klar, welche Daten abfließen. Bei Open-Source-Software kann dies über den Quellcode überprüft und ggf. eine angepasste Version ohne Datenabfluss entwickelt werden. Verschiedene Linux-Distributoren tun dies, um den Abfluss von Telemetriedaten an Open-Source-Projekte zu verhindern.
Proprietäre Software sammelt viele Daten. Meistens handelt es sich dabei um Nutzungsdaten. Eine Abschaltung ist in den seltensten Fällen möglich. Dies kann durch Netzwerkfilter reduziert werden.
Gefahr durch Kriminalität
Die Angriffsvektoren für Kriminelle sind in der Regel softwareunabhängig, da der Angriff nicht über den Entwicklungsprozess, sondern beim Endkunden erfolgt. Das Haupteinfallstor sind verschiedene Phishing-Varianten und Social Engineering. Hier geht es darum, sich Zugang zu den Systemen zu verschaffen.
Daneben sind zwei weitere Faktoren problematisch: Fehlkonfigurationen eigentlich sicherer Software und veraltete Softwareversionen sowie verzögerte Updates. Die eingesetzte Software ist dabei weniger wichtig als die IT-Kompetenz der Betreuer vor Ort.
Fazit
Letztlich ist es für die allermeisten Anwender eine Vertrauensfrage, auf welches Prinzip er setzt. Sowohl quelloffene Betriebssysteme und Softwareprojekte, als auch ihre proprietären Pendants haben in den letzten Jahren genug Anlass zu geben zu (ver)zweifeln.
Den meisten Nutzern wird es nicht möglich sein, den Quellcode mit dem nötigen Fachwissen zu betrachten und selbst jenen die dies könnten, fehlt häufig die Zeit. Das Audit der wichtigen Verschlüsselungssoftware TrueCrypt beanspruchte schließlich nicht umsonst sehr viel Arbeitszeit. Ein Audit, dass ohne frei zugänglichen Quellcode nicht möglich gewesen wäre, aber auch so bleiben Zweifel ob die Binärdateien aus diesem Quellcode gebaut wurden.
Es ist auch keineswegs so, dass die Entwickler von Open-Source-Software grundsätzlich sensibler für Datenschutzfragen sind als die Entwickler proprietärer Software.
Für viele Angriffsvektoren spielt es sogar keine Rolle, ob die Software proprietär oder quelloffen entwickelt wurde.