Proprietäre vs. Open-Source-Software
Die ewige Debatte um die Sicherheit
von Gerrit Kruse

Proprietär oder quelloffen, das ist hier die Frage! (Microsoft Clip Art)
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. Der Artikel soll etwas mehr Aufklärung bieten.
In der Sicherheitsfrage werden viele Aspekte vermischt. Es geht einerseits um die grundsätzliche Sicherheit vor schädlichen Programmen, ebenso wie dem Schutz vor Überwachung und Datenabschöpfung andererseits.
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, dies 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 wortwörtlichen Sinne, d. h. ein absolutes Gesichertsein vor Beeinträchtigungen jedweder Art, ist ein Zustand, dessen man sich bei Software nie gewiss sein kann. Fehlerfreiheit und die Abwesenheit von Sicherheitslücken ist ein Momentzustand — bis die nächste Sicherheitslücke bekannt und anschließend mit einem 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 der folgenden 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 (Hintertüren) für Geheimdienste in dem Bereich 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 Cloud-Dienste verleiten den Benutzer offensichtlich dazu, seine Daten vom heimischen Betriebssystem in das Netz einzuspeisen. Solche Herstellerdienste sind in modernen Betriebssystemen oft fest implementiert.
Ist ein System weniger sicher?
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, sondern kann jedwede Software betreffen. In der Praxis und in diesem Artikel ist diese Reduktion jedoch sinnvoll, da eine unsichere Basis jeglicher Sicherheit den Boden entzieht. 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. Zudem spielen freie Alternativen wie die BSD-Familie lediglich eine Nischenrolle und die Kritikpunkte an Microsoft Windows lassen sich auch auf das proprietäre Mac OS X von Apple übertragen. [Anmerkung des Betreibers: Mit BSD-Familie ist Software unter der BSD-Lizenz bezeichnet, einer Gruppe von Lizenzen aus dem Open-Source-Bereich, die frei verwendet werden darf. Der Urtyp der Lizenz stammt von der University of California, Berkeley, worauf das Akronym BSD für Berkeley Software Distribution hinweist.]
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. Offensichtlich dürfte es für Kriminelle interessanter sein sich auf Windows zu fokussieren. Das hat erst einmal nichts mit der Sicherheitsarchitektur zu tun. Dieses Argument wird dadurch gestärkt, dass Mac OS X unter Fachleuten als relativ unsicher gilt, aber bisher noch keine größeren Probleme mit Schadprogrammen hat (es gab allerdings bereits ein paar in freier Wildbahn). 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 nicht zuletzt daran, dass der Nutzer von Haus aus mit Administratorrechten im System angemeldet war. Seitdem hat Microsoft viel an der Sicherheitsarchitektur von Windows verändert und liefert seit Windows 8 auch einen eigenen Virenscanner aus — Aspekte, die gerne unterschlagen werden. 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.
Umgang mit Sicherheitslücken
Dennoch gibt es 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 beseitigt wurden.
Hinzu kommt die Tatsache, dass viele proprietäre Softwareprojekte festgelegte Zyklen für die Veröffentlichung von Fehlerbehebungen haben, sogenannte Patch Days. Dies trifft z. B. für Adobe, Microsoft und Oracle zu. 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 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.
Verfechter von Open-Source-Software 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.
Zum Autor: Gerrit Kruse ([Mer]Curius) nutzt Linux seit 2007. Als Wissenschaftler stehen Datenschutz und produktives Arbeiten auf dem Linux-Desktop im Vordergrund seiner Interessen.
(Siehe auch aus Pro-Linux „Britische Regierung stuft Ubuntu 12.04 LTS als sicherstes Client-Betriebsystem ein“ vom 14. Januar 2014 und hier beispielsweise auch „Liebe Thunderbird-Entwickler“ und „XP ade, Linux juchhe?“!)
Kommentare
Proprietäre vs. Open-Source-Software — Ein Kommentar
HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>