Proprietär vs. Open Source – Die ewige Debatte um die Sicherheit
Security through Obscurity?
Der Satz kommt eigentlich aus dem Netzwerbereich, wird aber inzwischen auch oft auf proprietäre, geschlossene Software angewandt. So wird argumentiert, dass die Nichtfreigabe 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 mit finanziellen Anreizen für Personen, 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 Programmierern (manchmal auch nur einer) über Jahre hinweg ein Projekt. Es gibt hier also eine sehr beschränkte Anzahl von Personen, die den Code wirklich kennen und verstehen. Das betrifft nicht nur irgendwelche kleinen Nischenprojekte mit eher geringer Relevanz, sondern auch große und zentrale Bestandteile der Open-Source-Welt.
Bekannt wurde dieser Umstand 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 in das 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. Einen wirklichen Vorteil gibt es hier für kein Prinzip.
Seit den Enthüllungen von 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 zu schweigen. Gerade der Heartbleed-Fall zeigt aber auch, dass es keineswegs unmöglich wäre, in quelloffene 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 sogenannten 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.
Letztlich ist es für die allermeisten Anwender eine Vertrauensfrage, auf welches Prinzip sie setzen. Sowohl quelloffene Betriebssysteme und Softwareprojekte als auch ihre proprietären Pendants haben in den letzten Jahren genug Anlass gegeben 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, das 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, das 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 oder den pummeligen Pinguin nutzt.
Autoreninformation
Gerrit Kruse (Webseite) ([Mer]Curius) nutzt Linux seit 2007. Als Wissenschaftler stehen Datenschutz und produktives Arbeiten auf dem Linux-Desktop im Vordergrund seiner Interessen.
Dieser Artikel ist in freiesMagazin 10/2015 (ISSN 1867-7991) erschienen. Veröffentlichung mit freundlicher Genehmigung.
