Eine Sicherheitslücke in der Open-Source-Bibliothek OpenSSL sorgt in den letzten Tagen für viele Schlagzeilen: Durch einen simplen Programmierfehler ist es möglich, bei betroffenen Web- und E-Mail-Servern interne Speicherinhalte auszulesen. Die Lücke blieb bei den Projektverantwortlichen rund zwei Jahre unentdeckt und wurde anscheinend auch aktiv ausgenutzt (siehe hier oder hier).

Eine gute technische Zusammenfassung der Ursachen gibt es bei Sean Cassidy. (Spoiler: der Fix ist extrem simpel.)

Aber was kann man als Software-Entwickler aus dem »SSL-Gau« lernen? Aus meiner Sicht demonstriert Heartbleed ein paar wichtige Punkte auf drastische Art und Weise:

Eingabedaten sind immer zu validieren
Eigentlich eine Binsenweisheit, offensichtlich aber beherzigen das nicht einmal angehende Informatiker zum Ende ihres Studiums: jede Benutzereingabe hat validiert zu werden. Immer. Ausnahmslos. Im Falle des Heartbleed-Bugs bedeutet das konkret, zu überprüfen, ob die Länge der gesendeten Daten tatsächlich übereinstimmt mit der ebenso gesendeten Längenangabe. Easy, oder?

Als Anwender sollte man für jeden Dienst ein eigenes Kennwort verwenden
Auch dieser Hinweis ist eigentlich simpel und liegt auf der Hand. Wenn schon die Zugangskennung für einen Dienst entwendet wird, ist es enorm hilfreich, wenn mit derselben Kennung nicht auch gleich etliche andere Dienste zugänglich sind. Wer Schwierigkeiten hat, sich Passwörter zu merken, oder wer besonders sichere Passwörter haben möchte, der sollte einen Password Safe einsetzen. Es gibt mittlerweile einige sehr schöne Anwendungen für Smartphones, so dass man seine Kennwörter auch immer dabei haben kann.

C ist unsicher
Zugegeben: diese Aussage ist etwas plakativ und zugespitzt. Und vielleicht ist diese Aussage auch die schmerzvollste Lehre aus dem Heartbleed-Bug. Sicherlich ist C nicht zu unrecht eine der wichtigsten Programmiersprachen überhaupt, wenn nicht sogar die wichtigste Programmiersprache. Natürlich ist es möglich, bombensichere und fehlerfreie Software in C zu entwickeln. Andere Programmiersprachen haben auch ihre Schwächen, und ja: in jeder Programmiersprache kann man Müll zusammenschreiben. Leider ist es aber auch definitiv so, dass C es einem Entwickler extrem leicht macht, sich ins eigene Knie zu schießen, indem (wie hier) versehentlich auf Speicherbereiche zugegriffen werden kann, auf die man nicht zugreifen will und soll. Die flexible Struktur von C erschwert außerdem Werkzeugen zur Code-Analyse die Arbeit. Der Umgang mit Strings und Arrays, die Implementierung von eigenen Methoden zur Speicherverwaltung … die Schwachstellen von C sind zahlreich und grundlegend und bedürfen sehr viel Erfahrung, um souverän damit umzugehen.
Da drängt sich ganz selbstverständlich die Frage auf, ob es nicht an der Zeit ist, für die Entwicklung gerade von sicherheitskritischen Werkzeugen höhere Sprachen bzw. Systeme einzusetzen. Welche Alternativen da in Frage kommen, lasse ich einmal offen.

Open Source bedeutet nicht automatisch Sicherheit
Als ein Argument für Open-Source-Software (OSS) wird immer wieder die ageblich überlegene Sicherheit genannt, die sich aus der Tatsache ergebe, dass jedermann die Software einsehen und notfalls korrigieren könne. Das ist natürlich Blödsinn. In der Praxis funktioniert das eher selten, und deshalb ist OSS auch nicht prinzipiell besser oder sicherer als proprietäre Alternativen. Die sind allerdings ebenso wenig pauschal besser. Anders ausgedrückt: das Modell »Open Source« sagt rein gar nichts über die Qualität der Software aus.

Große Verbreitung bedeutet auch eine große Verantwortung
Gerade einmal elf Entwickler kümmern sich regelmäßig um die OpenSSL-Bibliothek, genutzt wird sie praktisch von der ganzen Welt. Und ein solches Software-Projekt lässt es zu, dass ein junger Informatik-Student anscheinend ohne großartigen Review-Prozess kritische Code-Teile einreicht. Muss das sein? Die großen Nutznießer der OpenSSL-Bibliothek setzen sie in ihrer kritischen Infrastruktur ein, ohne sich selbst an der Entwicklung zu beteiligen oder wenigsten aus Eigeninteresse ein Qualitätsmanagement zu betreiben.

Sollte hier nicht ein Umdenken erfolgen? Ein OSS-Projekt mit der riesigen Bedeutung und Verbreitung wie OpenSSL sollte nicht nur Selbstbedienungsladen sein, sondern auch von den Unternehmen unterstützt werden, die am meisten davon profitieren.

Zu diesem Thema gibt es auch an andere Stelle viele Meinungen und Denkansätze:

• ZEIT Online: Die unbequeme Wahrheit über Open Source
• jaxenter: Nach Heartbleed die Open-Source-Apokalypse? Über Bugs und Denkfehler
• The Wallstreet Journal: Heartbleed: SPD will Open-Source-Sicherheit staatlich unterstützen
• Kristian Köhntopp mit einem Beitrag bei Google+