Die Flinke Feder: Mit Sicherheit nicht

Ich bin Open-Source-Entwickler. Trauen Sie mir?

Bernd Fondermann

Ich bin Open-Source-Entwickler. Trauen Sie mir? Würden Sie mir den Schlüssel zu Ihrer Wohnung anvertrauen? Oder einem Open-Source-Entwickler aus, sagen wir, Washington D.C.? Würden Sie einen jungen aufstrebenden chinesischen Informatikstudenten in Ihre Wohnung lassen, wenn er unangemeldet vor der Tür stünde? Steve Ballmer, trauen Sie wenigstens dem? Oder Mark Zuckerberg? Haben Sie auf alle diese Fragen uneingeschränkt mit Ja geantwortet, frage ich mich, warum Sie überhaupt noch eine Wohnungstür haben. Für Sie ist diese Kolumne jetzt zu Ende. Allen anderen gratuliere ich zu Ihrer Ehrlichkeit. Nun die nächste, die entscheidende Frage: Wenn Sie einer dieser Personen nicht vertrauen, warum in aller Welt überlassen Sie uns dann den Schlüssel zu Ihrer digitalen Wohnung? Tun Sie gar nicht? Tun Sie doch: Auf Ihrem Notebook läuft Windows. Ihr DSL-Modem wird mit – Sie ahnen es vielleicht gar nicht – FreeBSD betrieben. Sie legen Ihre Daten bei Facebook ab, d. h. auf Servern, die unter Linux laufen.

Bei den Millionen und Abermillionen Zeilen von Quellcode, die in allen möglichen Produkten vom Router über das Telefon bis zum Laptop stecken, gibt es genügend Sicherheitslücken, die aus Dummheit oder Unvollkommenheit entstanden sind. Aber doch bestimmt auch so einige Hintertüren, die absichtlich eingebaut wurden [1].

Machen wir uns doch nichts vor: Open Source basiert auf der Arbeit von Freiwilligen. Die sicher in manchen Fällen auch, sagen wir, ethische Kompromisse eingehen würden, wenn sie nur jemand für die Arbeit an ihrem Lieblingsprojekt bezahlen würde. Überdurchschnittlich. Zum Beispiel ein Geheimdienst. Es ist sicher auch kein Ding der Unmöglichkeit für solche Institutionen, eigene Mitarbeiter mit dem Ziel der Einflussnahme quasi als Entwickleragenten auf dem herkömmlichen legalen Weg in die Projekte „einzuschleusen“. Codebeiträge zu Open Source werden vielleicht ein bisschen besser von der Community überprüft, als proprietäre In-House-Projekte. Aber in der Regel sind die Reviews immer noch recht lückenhaft.

Bitte nicht gleich das Heft verärgert in die Ecke werfen. Ja, man hat Ihnen immer wieder erzählt, dass Open Source sicher sei, weil alles sichtbar und offen für jedermann entwickelt wird. Aber es muss ja auch jemand hinschauen. Und dann noch verstehen. Und im Fall eines Fehlers seine Behebung initiieren. Und genau dieser Prozess findet einfach nicht immer statt. Das ist der große Unterschied zwischen Offenheit (Kann ich schauen?), Transparenz (Kann ich verstehen?) und Sicherheit (Kann ich die Harmlosigkeit einer Software verifizieren?).

Bei Apache ist durchgehend das Prinzip des Peer Reviews etabliert. Alle Änderungen am Code, an Websites und Wikis werden als Subversion Commit Logs an die entsprechenden Entwickler-Mailinglisten gesendet. Auch Releases werden im Rahmen des Releaseprozesses von mindestens sechs Augen angeschaut. Weitere Kontrollpunkte gibt es nicht. Vertrauen in Apache-Software ist also tatsächlich das Vertrauen in seine Committer.

Bei Apache wurde vor einiger Zeit ein neues Tool eingeführt: Das Review Board [2], das von einigen Projekten schon genutzt wird. Dieses Werkzeug hilft dabei, prozessgestützt systematisch sicherzustellen, dass Veränderungen am Code durch eine zweite Person geprüft werden. Peer Reviews helfen sicher eine Menge. Sorgfältig verborgenen, absichtlichen Sicherheitslücken wird man so nicht Herr werden können. Denn es wird auch die Kunst der Verschleierung angewendet. Eine Kunst, die sogar in einem Wettbewerb zur höchsten Vollendung kommt [3].

Traut der Autor dieser bescheidenen Kolumne denn Open-Source-Entwicklern? Jein. Kein Entwickler hat bei mir einen Freifahrtschein, nur weil er Open Source entwickelt oder sich bei Apache engagiert. Aber die Entwickler, mit denen ich direkt zusammenarbeite, denen vertraue ich. Genau wie im echten Leben. Trotzdem schaue ich mir ihren Code an.

Ich bin mir sicher – obwohl ich es nicht weiß -, dass es Entwickler gibt, die im Auftrag von Geheimdiensten und Unternehmen mit ähnlichen Interessen nach Schwachstellen in Linux, Tomcat und WordPress suchen, um diese Lücken gezielt ausnutzen zu können. Mit Stuxnet ist zumindest ein Fall bekannt, wo eine Lücke in kommerzieller Anlagensteuerungssoftware ausgenutzt wurde [4]. Die im Dezember aufgeflammte bizarre Debatte um die Integrität des OpenSSH Stacks [5], einen der zentralen Pfeiler der IT-Sicherheitsinfrastruktur zeigt, wie schwierig der Umgang mit diesem Thema im Open-Source-Bereich ist. Open Source ist definitiv interessant, um dort gut getarnt Hintertüren und Lücken einzubauen. Es wird aber auch klar, wie viel Aufwand man betreiben muss, um eine ausbeutbare Lücke einzubauen, und wie viel schwerer es ist, sie zu enttarnen. Schnell wird es auch für die Beteiligten undurchsichtig [6].

Wie werden wir dieser Situation Herr? Brauchen wir eine Stiftung SoftwareTest? Das wäre ein Lösungsansatz. Absolutes Vertrauen ist naiv und gefährlich. Zumindest gibt es bei Open Source die Möglichkeit, den Quellcode zu analysieren, zu verändern und selbst zu kompilieren. Vertrauen Sie sich selbst.

Bernd Fondermann (bernd.fondermann[at]brainlounge.de) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt am Main. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop und Lucene und ist Member der Apache Software Foundation und Vice President Apache Labs.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.