Ist Open Source Software wirklich sicherer?
Open Source-Software gilt als sicherer als proprietäre Software - doch stimmt das wirklich? Wir machen den Praxis-Check.
- Anna Kalinowsky
Hand aufs Herz: Wissen Sie exakt über alles Bescheid, was der Browser tut, den Sie gerade verwenden? Neben Ihren Kenntnissen in Sachen Softwareentwicklung hängt das vor allem davon ab, welchen Browser Sie gerade verwenden. Denn: Nutzen Sie einen quelloffenen Browser wie Mozilla Firefox, könnten Sie den Quellcode inspizieren und bis ins Detail prüfen, was beispielsweise beim Aufruf einer Webseite passiert. Geschlossene Browser wie Microsoft Edge oder Apple Safari bieten diese Möglichkeit nicht. Tatsächlich gilt: Nur bei Open-Source-Programmen können Sie wirklich wissen, was drinsteckt.
Transparenz als Sicherheitskonzept
Die Idee, dass ein für Jedermann einsehbarer Quellcode für mehr Sicherheit sorgen kann, wirkt im ersten Moment paradox: Könnten nicht auch Angreifer den Code prüfen und Schwachstellen ausnutzen? Ja, könnten sie und tun es auch immer wieder. Doch eine aktive Entwicklergemeinde kann ebenso schnell dafür sorgen, dass die entsprechenden Probleme behoben werden. Vor allem sicherheitsrelevante Tools wie Verschlüsselungsprogramme profitieren von diesem Konzept. In sogenannten Security-Audits werden große Open-Source-Programme auf Probleme abgeklopft – ein Prozess, der bei Closed-Source-Programmen mangels Quellcode nicht möglich ist.
Ein potenzieller Vorteil des quelloffenen Konzepts besteht zudem darin, dass der Code von anderen Entwicklerteams aufgegriffen und eigenständig weiterentwickelt werden kann – man spricht von einer sogenannten „Fork“. So geschehen etwa beim 2014 eingestellten Verschlüsselungstool TrueCrypt. Nachdem das Originalprogramm aufgrund mangelnder Sicherheit nicht mehr weiterentwickelt wurde, hat ein anderes Team die Programmbasis unter dem Namen VeraCrypt fortgeführt (genau genommen startete die Entwicklung von VeraCrypt freilich schon vor dem Ende von TC, ohne den Open-Source-Gedanken wäre sie aber nicht möglich). VeraCrypt liefert gleich auch ein Beispiel für einen erfolgreichen Audit: Gefundene Sicherheitslücken im Quellcode wurden durch die Entwicklergemeinde schnell geschlossen.
Keine Sicherheitsgarantien
Ob Open oder Closed Source: Für beide Konzepte finden sich Befürworter, die die Sicherheit propagieren. Eine Garantie für die perfekte Sicherheit können aber beide nicht liefern.
Das vielleicht „einfachste“ Exempel dafür, dass geschlossener Code nicht automatisch in mehr Sicherheit resultiert, liefert Microsoft mit seinem Betriebssystem Windows. Monat für Monat kommen neue, nicht selten schwere Sicherheitslücken in Windows zum Vorschein. Microsoft reagiert darauf mit dem Patch Tuesday, an dem die Entwickler aus Redmond im Monatsturnus Patches verteilen. Die Windows-Nutzer müssen sich darauf verlassen, dass die Windows-Macher dabei einen guten Job machen - anders als etwa bei Linux haben passionierte Entwickler keine Chance, Codefehler in Windows selbst zu beheben. Unabhängig davon können Sie sich nie sicher sein, was Windows gerade im Hintergrund alles macht. Nicht zuletzt durch Windows 10 und seine bis heute nicht vollständig transparente Datensammelei ist dies ein großer Malus von nicht-offener Software. Das Gleiche ist natürlich kein Microsoft-exklusives Problem, sondern lässt sich auf jedes beliebige Closed-Source-Programm übertragen.
Das Gegenbeispiel liefern Open-Source-Systeme wie Linux oder BSD. Hier kann theoretisch jeder Entwickler auf eigene Faust Sicherheitslücken schließen – natürlich müssen die entsprechenden Änderungen auch in den „offiziellen“ Code übernommen werden. Fehler und Sicherheitslücken im Linux-Kernel werden erfahrungsgemäß schnell durch die Entwicklergemeinde behoben. Doch das ist nur die halbe Miete: Kommen die Patches nicht beim Nutzer an, bringt es wenig. Auch hier liefert ein großes Betriebssystem ein Negativbeispiel, nämlich Android. Auf Millionen von Smartphones laufen völlig veraltete Versionen von Googles auf Linux basierenden Mobilsystem. Nicht nur nicht-gepatchte Linux-Lücken, sondern auch fehlende Sicherheitskonzepte von Google sind dann ein Problem. Immerhin gibt es zumindest theoretisch die Möglichkeit, neue Android-Versionen über das Android Open Source Projekt zu erstellen – Entwicklergemeinden wie XDA-Devs springen hier mit sogenannten Custom-ROMs in die Bresche – der Aufwand dafür ist aber groß, die Ergebnisse nicht immer zufriedenstellend. Außerdem kann man auch bei offenem Quellcode nicht sicher sein, dass die daraus erzeugten Programme tatsächlich von diesem Quellcode stammen und nicht zwischendurch manipuliert wurden.
Mischkalkulation
Häufig integrieren große, proprietäre Programme auch Open-Source-Projekte für bestimmte Funktionen. Ein Beispiel dafür ist der populäre Smartphone-Messenger WhatsApp. Während der Basis-Code von WhatsApp geschlossen ist, basiert die 2014 eingeführte Ende-zu-Ende-Verschlüsselung auf den quelloffenen Diensten von Open Whisper Systems. Tatsächlich gilt die auch im alternativen Messenger Signal verwendete Nachrichtencodierung bislang als unknackbar, obwohl die genutzten Protokolle offen einsehbar sind. Was genau das 2014 von Facebook erworbene WhatsApp aber jenseits der Nachrichtenverschlüsselung alles tut, lässt sich nicht ohne weiteres herausfinden – zumindest so lange, wie die WhatsApp-Macher den Code der App nicht freilegen.
Ob Open Source oder nicht: Wie sicher und zuverlässig ein Programm arbeitet, hängt immer auch davon ab, wer für die Entwicklung zuständig ist. Ein sicherheitsrelevantes Programm, an dem seit Jahren nicht mehr gearbeitet wird, sollten Sie auch bei offenem Quellcode zumindest mit Skepsis betrachten. Ist der Code hingegen sauber dokumentiert, befassen sich viele Programmierer mit der Weiterentwicklung ist die Chance, ein sicheres Open-Source-Projekt vor sich zu haben, zumindest hoch.
Vertrauensfragen
Wir halten fest: Ist der Source-Code geprüft und werden gefundene Sicherheitslücken schnell durch die Entwicklergemeinde gestopft, sind aktive Open-Source-Projekte absolut sicher. Oder? Leider nein, zumindest nicht ohne Einschränkung. Wenn Sie sich ein „fertiges“ Open-Source-Programm herunterladen, müssen Sie nämlich darauf vertrauen, dass der saubere Quellcode nicht manipuliert wurde. Ein Beispiel: Laden Sie den schon erwähnten Firefox aus einer möglicherweise dubiosen Quelle herunter, kann es durchaus sein, dass jemand Schadsoftware in den Code integriert hat. Schließlich muss der Quellcode vor der Nutzung erst einmal in ein fertiges Programm umgewandelt, also mit einem Compiler kompiliert werden. Da Sie den Originalquellcode nicht ohne Weiteres einsehen können.
Die Lösung für Skeptiker könnte also bedeuten: Selber kompilieren. Laden Sie sich einfach den nachgewiesen sauberen Quellcode herunter, jagen Sie ihn durch den Compiler Ihrer Wahl und schon haben Sie ein sicheres Open Source-Programm. Doch auch hier gibt es ein „Aber“: Sie müssen natürlich auch dem Compiler vertrauen. Den Hintergrund liefert der sogenannte Ken-Thompson-Hack. Der Informatiker demonstrierte in den 1980er-Jahren, dass ein korrumpierter Compiler eine gefährliche Hintertür in ein Programm mit sauberem Source-Code einbauen könnte – und das, obwohl im Quellcode des Compilers davon nichts zu sehen ist. Theoretisch müssten Sie für einhundertprozentige Sicherheit also nicht nur das Programm kompilieren, sondern auch den dafür verwendeten Compiler selber schreiben, natürlich mit einem komplett „sauberen“ System. Diese Gedanken ließen sich beliebig fortführen, auch wenn es mittlerweile Prüfkonzepte gegen den Ken-Thompson-Hack gibt.
Zugegeben: Langsam bewegen wir uns auf einer Ebene, auf der der Sicherheitsgedanke beinahe an der Paranoia grenzt. In der Praxis zeigt sich aber, dass ein Schwarz-weiß-Denken beim Umgang mit Open- oder Closed-Source-Software nicht die beste Idee ist. Weder ist Open Source pauschal sicherer, noch ist proprietäre Software durch die Bank nebulös. Die Wahrheit liegt wie so oft irgendwo in der Mitte.
(anka)
