Ist Open Source Software unsicherer als kommerzielle Software
Seit vor ein paar Jahren die ersten Sicherheitslücken in Microsoft Windows bekannt wurden, vertraten viele Experten die Ansicht, dass Open Source Software (kurz OSS) – damals ging es primär um Linux – sicherer als kommerzielle Software (insbesondere Windows) sei. Die Begründung war ganz einfach: bei OSS kann jeder den Quelltext einsehen und so fallen Programmierfehler viel schneller auf und können auch entsprechend schnell behoben werden. Quasi eine Crowd-basierte permanente Qualitätskontrolle. Als Beweis für diese These wurde immer wieder angeführt, dass es unter Linux quasi keine Viren oder Trojaner gäbe.
Ich habe schon damals diese allgemeine Einschätzung zur Sicherheit von OSS nicht geteilt. Wenn jeder Zugriff auf den Quellcode hat, dann können Sicherheitslücken (zumindest in der Theorie) wirklich schneller entdeckt werden. Aber nicht jeder, der eine solche Lücke entdeckt, ist auch an der Behebung interessiert. Es gibt genügend Personen (oder Organisationen), die diese Sicherheitslücken lieber für ihre (illegalen) Zwecke ausnutzen wollen. Auch das Einschleusen von Sicherheitslücken oder der Einbau von Backdoors ist bei OSS einfacher möglich, wenn Codeänderungen nicht von weiteren Entwicklern überprüft werden.
Der vor ein paar Wochen gefundene Heartbleed-Bug ist jetzt genau ein Beispiel, wo ein Programmierfehler in einer OSS über Jahre nicht behoben wurde. Noch schlimmer ist es aber, dass sich dieser Bug in einer sicherheitsrelevanten Software (OpenSSL) befindet, die von vielen Web Servern und Mail-Servern eingesetzt wird.
Hatte ich also Recht und OSS ist nicht wirklich sicherer als kommerzielle (bzw. “Closed Source Software”)? Zum Teil ja, aber man kann das nicht verallgemeinern. Sieht man sich Linux und insbesondere den Linux-Kernel an, so kann man davon ausgehen, dass hier solche Sicherheitslücken eher unwahrscheinlich sind. An Linux arbeiten weltweit hunderte von Entwicklern (und dann gibt es noch immer Linus Torvalds, der noch immer ein Auge auf den Kernel-Code hat). Ähnlich sieht es bei anderen Open Source Projekten aus, z.B. den diversen Projekten der Apache Software Foundation.
An OpenSSL arbeitete jedoch nur ein (!) fest angestellter Entwickler und sein Code wurde schlichtweg von zu wenigen anderen Entwicklern überprüft. Die Auswirkungen dieses Bugs waren dann so katastrophal, weil OpenSSL von sehr vielen Produkten mit Millionen von Nutzern (Web Servern, Mail Servern, Android etc.) verwendet wird. Die Lizenz erlaubt die Verwendung im kommerziellen Umfeld und natürlich ist es günstiger eine kostenlose Komponente zu verwenden, als eine Bibliothek, die Geld kostet … Aber anscheinend hat sich keiner der Nutzer mal den Quellcode angesehen.
Viele OSS-Projekte haben damit zu kämpfen, das die erstellte Software zigfach auch in kommerziellen Produkten genutzt wird, aber es häufig zu wenige aktive Entwickler oder Tester gibt (das gilt selbst für Projekte wie Eclipse). Auf Grund der geringen finanziellen Mittel können sich viele OSS-Projekte auch nur wenige oder gar keine fest angestellten Entwickler leisten. Wenn eine OSS auch kommerziell genutzt werden darf, dann sollten die kommerziellen Nutzer (im Fall von OpenSSL z.B. die Interner Provider) die Projekte auch unterstützen. Entweder finanziell oder in dem sie sich mit eigenen Programmierern an Entwicklung und Test beteiligen. Schließlich sparen sie durch die Nutzung von OSS viel Geld an Softwarelizenzen.
Fazit
Bei den großen Open Source-Projekten mit teilweise Hunderten Entwicklern, die sich im besten Fall gegenseitig kontrollieren, kann man davon ausgehen, das evtl. Sicherheitslücken rechtzeitig entdeckt und korrigiert werden. Aber je weniger Entwickler an einem Projekt arbeiten, desto größer ist die Gefahr von nicht entdeckten Programmierfehlern (und somit auch Sicherheitslücken). Gerade bei der Nutzung sicherheitsrelevanter Softwarebibliotheken sollte man daher vorsichtig sein und mal genauer hinschauen, ob es bei dem Projekt wirklich eine Qualitätskontrolle gibt. Falls nicht sollte man entweder auf die Nutzung verzichten oder das Projekt unterstützen, indem man selber einen Blick in den Quellcode wirft oder gezielt testet.
Ich selber nutze sowohl privat als auch beruflich viele Open Source-Produkte (Eclipse, Subversion, Hudson, Git, Linux, Apache, …). Aber abgesehen von Linux wird keines von diesen in sicherheitskritischen Bereichen eingesetzt.
