Proprietär vs. Open Source – Die ewige Debatte um die Sicherheit

Anzeige:

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. Dass dies eine eher ideologische Debatte ist, scheint erkennbar am ungenauen Einsatz von Begriffen, Szenarien und Argumenten.

030424-N-6536T-006 The Arabian Gulf (Apr. 24, 2003) -- USS Nimitz (CVN 68) transits the Arabian Gulf as it prepares for Flight Quarters. Nimitz Carrier Strike Force and Carrier Air Wing Eleven (CVW-11) are currently deployed in support of Operation Iraqi Freedom. Operation Iraqi Freedom is the multi-national coalition effort to liberate the Iraqi people, eliminate IraqiÕs weapons of mass destruction, and end the regime of Saddam Hussein. U.S. Navy photo by PhotographerÕs Mate 3rd Class Elizabeth Thompson. (RELEASED)

Die US Navy (hier USS Nimitz ) hat seit 2001 eine Open Source Strategie und zum Beispiel das TOR-Netzwerk miterfunden. (cc-by-sa/Elizabeth Thompson)

 

Besonders von Seiten der Open-Source-Beführworter wird gerne der Sicherheitsaspekt hervorgehoben. In der Sicherheitsfrage werden aber viele Aspekte vermischt. Es geht einerseits um die grundsätzliche Sicherheit vor schädlichen Programmen, aber auch um den Schutz vor Überwachung und Datenabschöpfung. Zuerst erklären wir die Begriffe und Definitionen: «Open Source», zu Deutsch «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. Der Unterschied von quelloffener und freier Lizenzen betrifft kaum die Nutzung, sondern fast aussschliesslich die kommerzielle Wiederverwendung. Open Source Software ist gegenüber freier Software kommerziell eingeschränkter. «Proprietär» beziehungsweise «geschlossen» ist in diesem Kontext jede Software, die lediglich als binäre Software verteilt wird und den Einblick in Code sowie jegliches Mitgestaltungsrecht grundsätzlich aussschliesst.

Anzeige:

Welche Gefahren sollen abgewendet werden?

Sicherheit im wortwörtlichen Sinne 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 anschliessend 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 grossen Unternehmen (und ggf. daraus folgender staatlicher Überwachung), Gefahr durch implementierte Dienste, derer man sich als Anwender nicht bewusst ist (korrespondiert mit Gefahr durch Datenabfluss), Gefahr durch Kriminalität.

Die Gefahren können durch verschiedene Anwender oder unterschiedliche Anwendungsszenarien jeweils unterschiedlich gewichtet werden. Jeder dieser Punkte setzt andere Aspekte voraus. So ist es unwahrscheinlich, dass Software gezielt Lücken für Kriminelle enthält, wohingegen Hintertüren, sogenannte “Backdoors”, für Geheimdienste ein omnipräsentes Thema sind – egal ob es sie schon gibt oder nicht. Spätestens seit Edward Snowdens Enthüllungen müssen wir jedoch davon ausgehen, dass Hintertüren zumindest in einigen Verschlüsselungstechniken und populären Public-Cloud-Diensten existieren.

Gefahr durch Datenabfluss muss noch nicht einmal durch eine Sicherheitslücke entstehen, sondern kann durch die Funktion einer Software bedingt werden. Besonders Cloud-Dienste wie Dropbox verleiten die Nutzer, ihre Daten vom heimischen Betriebssystem unverschlüsselt in das Netz einzuspeisen – über unverschlüsselte Leitungen. Solche Dienste sind sogar in modernen Betriebssystemen wie Windows fest implementiert.

Ist ein System weniger sicher?

Der Sicherheitsvergleich zwischen quelloffener und proprietärer Software wird allzu oft auf den Vergleich Linux versus Windows reduziert. Allerdings hat die Thematik eigentlich nichts mit beiden Betriebssystemen zu tun, sondern kann jede Software betreffen. In der Praxis und für diesen Artikel ist diese Reduktion jedoch sinnvoll, da bereits 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ässigen 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 OSX von Apple übertragen.

Immer wieder wird angemerkt, dass dies auch am unterschiedlichen Verbreitungsgrad liegt. Es ist schliesslich 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 ist es für Kriminelle interessanter, sich auf Windows zu fokussieren. Das hat erst einmal nichts mit der Sicherheitsarchitektur zu tun. Dieses Argument wird dadurch gestärkt, dass Mac OSX unter Fachleuten als relativ unsicher gilt, aber bisher noch keine grösseren Probleme mit Schadprogrammen hat (es gab allerdings bereits ein paar in freier Wildbahn). Auch hier dürfte noch die geringe Verbreitung eine Rolle spielen – was sich nach und nach aber auch ändert. Macs werden rund um den Globus seit Jahren immer populärer und sind seit Jahrzehnten besonders in der Schweiz sehr weit verbreitet.

Ein weiteres Problem ist, dass die Debatte oft nicht mit zeitgemässen 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 Administrator-Rechten im System angemeldet war. Seitdem hat Microsoft viel an der Sicherheitsarchitektur von Windows verändert. Seit Windows 8 ist mit “Microsoft Security Essentials” (das zuvor noch optional war) auch ein eigener Virenscanner integriert. 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 Benutzerrechte-Management bereits vorhanden sind. Andere Bereiche wie der unter Windows obligatorische Virenscanner sind bisher nicht notwendig mangels bekannter Schadsoftware. Dazu kommt, dass immer weniger Computer-Viren als Hauptsicherheitsproblem auftauchen, sondern die betriebssystem-unabhängigen Internet-Browser das Ziel von Schadprogrammen sind, um des Nutzers Kreditkarten-Nummern und Zugangs-Passwörter zu stehlen.

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 Software-Projekte festgelegte Zyklen für die Veröffentlichung von Fehlerbehebungen haben, sogenannte «Patch Days». Dies trifft zum Beispiel für Adobe, Microsoft und Oracle zu. Das heisst 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ängeln in der Linux-Distribution.

«Security through obscurity» ist

Der Satz kommt eigentlich aus dem Netzwerkbereich, wird aber inzwischen auch oft auf proprietäre, geschlossene Software angewandt. So wird argumentiert, dass duch die Nichtfreigabe des Codes die Kriminellen 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 weiss. Dies schlägt den Bogen zurück zum Umgang mit Sicherheitslücken.

Realitäten überlagern Theorie

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 grosser IT-Unternehmen gefunden und öffentlich gemacht, sofern das Unternehmen nicht fristgerecht reagiert. Gleichzeitig gibt es Programme mit finanziellen Anreizen für Personen, die Lücken finden und an das Unternehmen melden, beispielsweise Google.

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 grosse 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 behaupten, dass das theoretische Mehr-Augen-Prinzip von quelloffener Software 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.

Bedrohungsszenarien sind vielfältig

Wenn es um Sicherheit geht, muss man den Aspekt immer in Relation zu den erwarteten Bedrohungen setzen. Datenabfluss kann beispielsweise beabsichtigt sein. Es gibt genug Open-Source-Projekte, die Telemetriedaten erheben oder Daten in das Internet verlagern. Open Source schützt 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 Software-Projekt wird schliesslich 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 schliessen oder das Projekt dazu strukturell mal 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 schliesslich 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.

Die Entscheidung über das Ausmass staatlicher Überwachung trifft man eher an der Wahlurne als bei der Wahl des Betriebssystems.

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 so genannten 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 Ausmass staatlicher Überwachung trifft man 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 zweifeln oder je nach Charakter gar zu verzweifeln. 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 schliesslich 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.

(Gerrit Kruse, Marco Rohner)

Der Hauptautor Gerrit Kruse (Webseite [Mer]Curius) nutzt Linux seit 2007. Als Wissenschaftler stehen Datenschutz und produktives Arbeiten auf dem Linux-Desktop im Vordergrund seiner Interessen.

The following two tabs change content below.
Gast-Autor

Gast-Autor

Die Ansichten und Meinungen im Artikel entsprechen derjenigen des Gast-Autors und nicht zwingend von Greenbyte.ch.