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. Besonders von Seiten der Open Source-Gemeinde wird gerne der Sicherheitsaspekt von Open Source-Software hervorgehoben. Wie immer bei einer ideologisch unterfütterten Debatte wird es mit Begriffen, Szenarien und Argumenten nicht immer so genau genommen. In der Sicherheitsfrage werden viele Aspekte vermischt. Es geht um die grundsätzliche Sicherheit vor schädlichen Programmen, ebenso wie dem Schutz vor Überwachung und Datenabschöpfung.
Welche Gefahren sollen abgewendet werden?
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.
Sicherheit im wortwörtlichen Sinne, d.h. ein absolutes Gesichertsein vor Beeinträchtigen jedweder Art ist ein Zustand, dessen man sich bei Software nie gewiss sein kann. Fehlerfreiheit bzw. die Abwesenheit von Sicherheitslücken sind ein Momentzustand – bis die nächste Sicherheitslücke bekannt und anschließend per Update beseitigt wird. Die Sicherheitsdebatte ist also auch eine Frage wie mit Sicherheitslücken umgegangen wird.
Grundsätzlich muss man bei einer Sicherheitsdebatte konkretisieren, welche Gefahren man abwenden möchte. Grob vereinfacht können das einige sein (ohne Garantie auf Vollständigkeit):
- Gefahr durch staatliche Überwachung
- Gefahr durch Datenabfluss zu großen Unternehmen (und ggf. daraus folgender staatlicher Überwachung)
- Gefahr durch implementierte Dienste, derer man sich als Anwender nicht bewusst ist. (Korrespondiert mit Punkt 2)
- Gefahr durch Kriminalität
Dabei können die Gefahren durch verschiedene Anwender oder unterschiedliche Anwendungsszenarien jeweils unterschiedlich gewichtet werden. Jeder dieser Punkte impliziert andere Aspekte. So ist es recht unwahrscheinlich, dass Software gezielt Lücken für Kriminelle enthält, wohingegen Backdoors – d. h. Hintertüren – für Geheimdienste und Sicherheitsbehörden ein omnipräsentes Thema sind – egal ob es sie schon gibt oder nicht. Gefahr durch Datenabfluss muss noch nicht einmal durch eine Sicherheitslücke entstehen, sondern kann durch die Funktion einer Software bedingt werden. Gerade Clouddienste verleiten den Benutzer offensichtlich dazu ihre Daten vom heimischen Betriebssystem in das Netz einzuspeisen. Solche Herstellerdienste sind in modernen Betriebssystemen oft fest implementiert.
Angesichts der gegenwärtigen Situation sollte man die Gefahr durch staatliche Backdoors ausklammern (es gibt sie momentan nicht!) und den Datenabfluss an Unternehmen ebenso (es ist ein anderes Problem). Der Vergleich zwischen proprietärer und quelloffener Software muss sich daher auf Sicherheit und Sicherheitslücken konzentrieren. Diese bilden schließlich gegenwärtig die Grundlage für staatliche Überwachung und Kriminalität.
Gleichsetzung mit Linux vs. Windows
Der Sicherheitsvergleich zwischen quelloffener und proprietärer Software wird allzu oft auf den Vergleich Linux vs. Windows reduziert. Allerdings hat die Thematik eigentlich nichts mit beiden Betriebssystemen zu tun. Die Gleichsetzung von Linux und Sicherheit liegt unter anderem daran, dass Linux bislang durch relativ wenig Schadsoftware aufgefallen ist, während Windows in regelmäßigen Abständen Probleme mit Schadprogrammen hat. Aus diesem Grund spielt der Vergleich den Befürwortern von Open Source in die Hände.
Immer wieder wird angemerkt, dass dies auch am unterschiedlichen Verbreitungsgrad liegt. Es ist schließlich immer noch so, dass die unterschiedlichen Windows-Versionen zusammen den Markt für herkömmliche PC-Betriebssysteme dominieren, während Linux im niedrigen einstelligen Prozentbereich stagniert. Es ist also offensichtlich für Kriminelle interessanter sich auf Windows zu fokussieren. Das hat erst einmal nichts mit der Sicherheitsarchitektur zu tun. Dieser Aspekt wird dadurch gestärkt, dass macOS unter Fachleuten als relativ unsicher gilt, aber bisher noch keine größeren Probleme (es gab allerdings bereits ein paar in freier Wildbahn) mit Schadprogrammen hat. Auch hier dürfte die geringe Verbreitung eine Rolle spielen.
Ein weiteres Problem ist, dass die Debatte oft nicht mit zeitgemäßen Argumenten geführt wird. Insbesondere viele Argumente gegen Windows speisen sich aus der Vergangenheit. Windows war bis zur Version XP ein objektiv unsicheres und für die Internetnutzung unzureichend abgesichertes System. Dies lag ursächlich vor allem daran, dass der Nutzer von Haus aus mit Administratorrechten im System angemeldet war. Seitdem hat Microsoft viel an der Sicherheitsarchitektur von Windows verändert. Ein Aspekt, der gerne unterschlagen wird. Bei Linux hat sich hingegen in den letzten Jahren wenig getan. Allerdings nicht etwa, weil man nachlässig wäre, sondern weil viele Aspekte wie ein Benutzerrechtemanagement bereits vorhanden sind. Andere Bereiche wie der unter Windows obligatorische Virenscanner sind bisher – eben mangels bekannter Schadsoftware – nicht notwendig.
Die Gleichsetzung von proprietär mit Windows und Open Source mit Linux bringt die Debatte daher nicht weiter sondern blockiert die Analyse. Diese soll daher im folgenden am Beispiel des Umgangs mit Sicherheitslücken geschehen.
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 kommt eigentlich aus dem Netzwerkbereich, wird aber inzwischen auch oft auf proprietäre, geschlossene Software angewandt. So wird argumentiert, dass die Nicht-Freigabe des Codes Kriminelle daran hindert Sicherheitsmängel zu finden. Allerdings ist Windows das beste Beispiel dafür, dass man eben nicht den Quellcode haben muss um Sicherheitslücken ausfindig zu machen.
Open Source-Verfechter betonen hingegen, dass der frei zugängliche Quellcode es vielen unterschiedlichen Personen ermöglicht diesen zu prüfen, sowie Sicherheitslücken zu finden und zu melden. Die Software sei dadurch sicherer als geschlossene Projekte, wo Sicherheitsmängel unbemerkt über Jahre bestehen bleiben können – selbst wenn die dahinter stehende Firma davon weiß. Dies schlägt den Bogen zurück zum Umgang mit Sicherheitslücken.
Realitäten auf beiden Seiten
Abseits der Theorie, sieht die Realität auf beiden Seiten inzwischen häufig anders aus. So werden auch bei proprietären Projekten Sicherheitslücken von anderen Angestellten großer IT-Unternehmen gefunden und – sofern das Unternehmen nicht fristgerecht reagiert – öffentlich publik gemacht. Gleichzeitig gibt es Programme, die finanzielle Anreize für Personen bereitstellen, die Lücken finden und an das Unternehmen melden.
Auf der anderen Seite 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.
Bekannt wurde dieser Aspekt nicht zuletzt durch die Heartbleed-Lücke in OpenSSL. Hier offenbarten sich gleich mehrere Probleme. Ein über Jahre gewachsener Code, den kaum noch jemand durchblickte, eine viel zu dünne Personaldecke und ein schlechtes Qualitätsmanagement. Skeptiker des Open Source-Prinzips können seitdem – nicht ganz zu unrecht – behaupten, dass das theoretische Mehr-Augen-Prinzip von quelloffener Software oftmals faktisch nicht existiert. Dies gilt sogar dann – das hat Heartbleed gezeigt – wenn die Software von finanzstarken Unternehmen eingesetzt wird, die theoretisch über Personal verfügen, das den Quellcode betrachten könnte.
Zurück zu den Bedrohungsszenarien
Wenn es um Sicherheit geht muss man den Aspekt immer in Relation zu den erwarteten Bedrohungen setzen. Datenabfluss kann z. B. durchaus beabsichtigt sein. Es gibt genug Open Source-Projekte die Telemetriedaten erheben oder Daten ins Internet verlagern. Open Source schützt einen nicht vor einer beabsichtigten Funktion, auch wenn sich der Anwender nicht in jedem Fall der Konsequenzen bewusst ist. Android ist das beste Beispiel für ein Open Source Betriebssystem, das nicht datenschutzfreundlicher ausgelegt ist, als die proprietäre Konkurrenz.
Gleichzeitig kann man davon ausgehen, dass die meisten namhaften Firmen keine Schnittstellen für kriminelle Organisationen implementieren oder Daten in krimineller Absicht abgreifen. Diesen Punkt kann man für irgendwelche kleinen „Klitschen“ natürlich nicht geltend machen. Dafür ist bei proprietärer Software oftmals viel transparenter welche Firma hinter dem Projekt steht (oder eben auch nicht). Nicht jedes freie Softwareprojekt wird schließlich so transparent entwickelt, wie es die Theorie gerne hätte. Kriminelle können aber durchaus auch Zugang zu Sicherheitslücken haben – seien sie nun offiziell bekannt oder nicht. Es gibt allerdings auch bei freier Software Sicherheitslücken, die über einen längeren Zeitraum existieren, weil es nicht sofort möglich ist sie zu schließen oder das Projekt dazu strukturell gerade nicht in der Lage ist. Im Verlauf des Jahres 2015 lieferte Apche OpenOffice ein Beispiel hierfür. Einen wirklichen Vorteil gibt es hier für kein Prinzip.
Seit den Enthüllungen vom Edward Snowden über die weltweite Datenabschöpfung durch westliche Geheimdienste, steht die staatliche Überwachung (wieder) im Mittelpunkt der Sicherheitsdebatte. Insbesondere absichtlich implementierte Hintertüren werden immer wieder thematisiert. Rein theoretisch wäre eine solche Implementierung in proprietärer Software leichter, das Unternehmen dahinter wäre schließlich juristisch verpflichtet (je nach Firmensitz versteht sich) dies umzusetzen und zudem schweigen. Gerade der Heartbleed-Fall zeigt aber auch, dass es keineswegs unmöglich wäre in quelloffener Software eine solche Lücke einzuschleusen. Die Partizipationshürden sind oft niedrig und das Qualitätsmanagement nicht so gut, wie es sein müsste.
Es bleibt allerdings fraglich ob Hintertüren in Betriebssystemen die Bedeutung zukommt, die ihr in der öffentlichen Debatte eingeräumt wird. Moderne PC-Hardware verfügt über eine Vielzahl von Speichern und s.g. Firmwares. Sicherheitsforscher haben immer wieder hervorgehoben, dass es möglich und wahrscheinlich ist, Schadcode unsichtbar für Benutzer und Betriebssystem in den Geräten zu verankern. In diesem Fall wäre es vollkommen bedeutungslos ob das darauf installierte Betriebssystem quelloffen oder proprietär wäre. Die Entscheidung über das Ausmaß staatlicher Überwachung trifft man also eher an der Wahlurne, als bei der Wahl des Betriebssystems.
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. Ein Thema, dass auch durch die Open Source-Community zu selten thematisiert wird. Es ist auch keineswegs so, dass die Entwickler von Open Source-Software durchweg mehr für Datenschutzthemen sensibilisiert wären, als die Entwickler proprietärer Software. Man sollte sich jedenfalls nicht in Sicherheit wiegen. Egal, ob man Software des Weltmarktführers, der hippen Schmiede aus Kalifornien oder den pummeligen Pinguin nutzt.