Heartbleed – der Auslöser für LibreSSL (Teil 1)

Heartbleed – der Auslöser für LibreSSL (Teil 1)

Im April 2014 erschütterte die Sicherheitslücke Heartbleed die IT-Welt. Die Bibliothek OpenSSL, die auf vielen Servern zur Verschlüsselung eingesetzt wird, beispielsweise für HTTPS-Verbindungen, enthielt eine Schwachstelle. Dadurch war es entfernten Angreifern möglich, an sensitive Daten zu gelangen. Im Folgenden wird beleuchtet, wie Heartbleed und dessen Auswirkungen die Entwicklung des Betriebssystems OpenBSD und damit die Produkte von genua beeinflusst haben.

Wenn ein Angreifer etwa in den Besitz des geheimen Schlüssels eines Servers gelangt, kann dieser unbemerkt Man-in-the-Middle-Angriffe durchführen. Aufgrund der hohen Verbreitung von OpenSSL hat Heartbleed für viel Aufsehen gesorgt und Spuren hinterlassen.

Die Ursachen von Heartbleed

Unmittelbar nach Bekanntwerden von Heartbleed stellten sich viele die Frage, wie derart schwerwiegende Sicherheitslücken in Zukunft verhindert oder zumindest deren Eintrittswahrscheinlichkeit gesenkt werden könnte. Auch die OpenBSD-Entwickler, die für ihr hohes Sicherheitsbewusstsein bekannt sind, beschäftigten sich mit dem Problem und dessen Ursache. Als sie den OpenSSL-Code genauer analysierten, machte sich Entsetzen breit. Bereits ohne eine tiefergehende Prüfung wurde ein grundlegendes Problem in OpenSSL offensichtlich: Der Code war unübersichtlich und schwer zu verstehen. Es war nur schwer möglich, diesen nachzuvollziehen. OpenSSL enthielt zahlreiche Features, die praktisch nicht verwendet wurden, jedoch den Quellcode unnötig aufblähten.

Es wurden Byte-Reihenfolgen (engl. Endianness) auf Architekturen unterstützt, für die real gar keine Prozessoren existierten. Eine Byte-Reihenfolge legt fest, wie Daten im Speicher eines Computers abgelegt werden. Man unterscheidet hierbei Little-Endian und Big-Endian. Beim Little-Endian-Format wird das niederwertigste Byte an der kleinsten Speicheradresse abgelegt und das höchstwertigste Byte an der größten Speicheradresse. Beim Big-Endian-Format werden die Daten in umgekehrter Reihenfolge im Speicher abgelegt. Die bei PCs verbreiteten Architekturen i386 und amd64 unterstützten ausschließlich die Little-Endian Byte-Reihenfolge. OpenSSL enthielt jedoch Code, der eine Verarbeitung auf diesen Architekturen auch ermöglichen sollte, falls diese mit Big-Endian arbeiten sollten. Solche Prozessoren existierten jedoch nie!

Weiterhin schien der OpenSSL-Code auch noch 16-Bit-Windows-Systeme zu unterstützen, zumindest suggerierten dies einige Stellen im Code. Es ist fraglich, welchen Zweck dieser Code heute noch erfüllte und wann er zuletzt getestet wurde. Immerhin ist Windows seit Windows 95 32-Bit-fähig.

Umgangene Sicherheitsmechanismen

Bei einer tieferen Analyse der Sicherheitsprobleme machte OpenSSL keine bessere Figur. Die OpenBSD-Entwickler stellten fest, dass in OpenSSL Sicherheitsmechanismen des Betriebssystems und der Systembibliotheken nicht greifen, weil OpenSSL eigene Funktionen mitbringt, die diese Aufgaben übernehmen.

Heartbleed auf der Spur: Bei der tieferen Analyse von OpenSSL zeigten sich schwere Sicherheitsprobleme

Die Speicherverwaltung ist ein Beispiel für einen von OpenSSL umgangenen Sicherheitsmechanismus. Normalerweise fordert ein Programm mit der Funktion malloc() Speicher vom System an und kann ihn mit free() wieder freigeben. OpenBSD hat zahlreiche Mechanismen implementiert, die die Speicherverwaltung absichern. Mit free() freigegebene Speicherbereiche werden unter OpenBSD bis zu einer bestimmten Größe standardmäßig mit einem Pattern überschrieben, bevor sie von malloc() wieder vergeben werden. Mit diesem einfachen Prinzip kann man sicherstellen, dass man mit malloc() nicht zufällig Speicher erhält, der noch sensitive Daten von der vorhergehenden Nutzung enthält. Dieser Mechanismus hätte zwar die Heartbleed-Lücke nicht verhindern aber dafür sorgen können, dass der Angreifer nicht den noch im Speicher stehenden geheimen Schlüssel stehlen kann. OpenSSL hat jedoch einen eigenen Mechanismus zur Speicherverwaltung implementiert, der genau diese Funktionalität nicht bietet.

Man erkaufte höhere Geschwindigkeit durch Verzicht auf Sicherheit. Eine fragwürdige Priorisierung für eine Software, die in erster Linie entwickelt wurde, um Sicherheit zu gewährleisten.

Erfahren Sie im zweiten Teil dieses Beitrags, wie die Idee zu LibreSSL entstand, wie sich LibreSSL und OpenSSL unterscheiden und welche Auswirkungen die Umstellung auf LibreSSL für die Lösungen von genua hat.

 

Bildquelle: © SunnySideUp, Sergey Nivens - Fotolia.com


Lesen Sie auch

Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.