Software::Security
LibreSSL: Große Fortschritte in 30 Tagen
Der von OpenBSD kurzfristig geschaffene Fork von OpenSSL, LibreSSL, räumt den Quellcode der Kryptografie-Bibliothek gründlich auf. Zugleich lassen die OpenBSD-Entwickler kein gutes Haar an den OpenSSL-Entwicklern.
Codenomicon - www.codenomicon.com
OpenSSL: Schwerwiegender Fehler Heartbleed
Die Entwickler von
OpenBSD, einem freien und auf Sicherheit bedachten BSD-Unix-Betriebssystem, legten
vor knapp einem Monat einen eigenen Zweig von
OpenSSL an, nachdem sie infolge des katastrophalen
Heartbleed-Fehlers den Quellcode von OpenSSL angesehen und als unwartbar erkannt hatten. Es gab zwar sofort nach Heartbleed Initiativen, OpenSSL zu verbessern und finanziell zu unterstützen, damit sich mehr Entwickler darum kümmern können, doch OpenBSD geht das nicht weit genug, weil OpenSSL voll mit obsoletem Code ist.
So hat das Team auch, wie Bob Beck von OpenBSD in einem Vortrag erläuterte, erst einmal mit der Entfernung von sehr viel Code begonnen. Ausgangsbasis war die neueste OpenSSL-Version 1.0.1g. Entfernt wurde die Unterstützung für EBCDIC-Codierung, für veraltete Betriebssysteme wie DOS, Mac OS, VMS und alte Windows-Versionen. Sinnlose Neuimplementationen von Funktionen, die von modernen C-Bibliotheken bereitgestellt werden, mussten ebenso gehen wie viele andere Fehlentwicklungen.
Beck bezeichnet den Quellcode von OpenSSL als absolut grässlich. Das war wohl auch der Grund, warum ihn niemand gründlich anschaute, jedoch letztlich keine Entschuldigung. Jemand hätte trotz allem einen Audit des Codes vornehmen müssen. Das vielleicht schlimmste Fehldesign war die eigene Implementation eines Speicherallokators, die nie Speicher zurückgibt, beim Debuggen vertrauliche Daten in Logdateien schreibt und für Speicher-Debugging-Werkzeuge wie Valgrind und Coverity unzugänglich war, so dass diese keine Probleme aufdecken konnten. Zudem war der Allokator zur Laufzeit ersetzbar, eine Funktionalität, die niemand braucht.
Beck klagt außerdem die OpenSSL-Entwickler an, nicht an Korrekturen interessiert gewesen zu sein. Korrekturen von dritter Seite wurden nicht akzeptiert und gemeldete Fehler ignoriert, stattdessen wurden neue Funktionen eingebaut. Die OpenSSL-Foundation nahm eine Million US-Dollar im Jahr durch Beratung, vor allem für FIPS-Konformität ein. Wahrscheinlich waren die OpenSSL-Entwickler sehr zufrieden mit der Situation, dass ihnen niemand Konkurrenz machen konnte.
LibreSSL soll dies alles ändern und ein vollständig kompatibler Ersatz für OpenSSL werden. Der Code soll aufgeräumt werden, so dass er verständlich wird. Dabei sollen Fehler korrigiert und moderne Programmierpraktiken eingesetzt werden. Die Portabilität soll durch geeignete Maßnahmen sichergestellt werden, wobei ein POSIX-System vorausgesetzt wird und Unterschiede zwischen den Systemen mit einfachen Kompatibilitätsfunktionen ausgeglichen werden.
So wurde auch der Speicherallokator durch Standard-Funktionen ersetzt, und seither lassen sich die Standard-Werkzeuge auf den Code anwenden und weitere Fehler finden. Entfernt wurde auch der Entropie-Generator, der laut Beck extrem schlecht war. Entropie muss vom Betriebssystem (/dev/random, /dev/urandom) bereitgestellt werden. Weitere Aufräumarbeiten müssen an den Header-Dateien stattfinden. OpenSSL führte nahezu jede Funktion in den Header-Dateien auf, auch solche, die nur intern benutzt werden sollen. LibreSSL versucht, unter anderem durch Integrationstest in den Ports, herauszufinden, welche Funktionen wirklich öffentlich sein müssen und welche nicht.
Von den 388.000 Zeilen Code von OpenSSL hat LibreSSL inzwischen 150.000 entfernt, dabei viele Fehler korrigiert und den Code viel lesbarer gemacht. Das Team hat aber bereits damit begonnen, neue Verschlüsselungsalgorithmen hinzuzufügen, die allerdings strikten Qualitätsanforderungen genügen müssen. Dazu gehören BrainPool, ChaCha, poly1305 und ANSSI FRP256v1 sowie zugehörige Verschlüsselungs-Suites. FIPS (Federal Information Processing Standard) wird von den Entwicklern als schädlich angesehen und ist ausdrücklich kein Ziel von LibreSSL. Sollte jedoch jemand LibreSSL durch den FIPS-Prozess bringen wollen, werden sich die Entwickler dem nicht entgegenstellen. Die dabei geforderten Algorithmen dürfen aber nicht standardmäßig aktiv sein und müssen sauber implementiert sein.
Nach allen Änderungen ist LibreSSL immer noch kompatibel mit OpenSSL, da für alle entfernten Funktionen ein gleichnamiger Ersatz geschaffen wurde. Künftig wird das wohl nicht mehr der Fall sein. Das Team plant unter anderem, das API und den Code weiter zu reduzieren, libcrypto aufzuspalten und libcrypto von libssl zu trennen. Dinge wie der ASN.1-Parser sollten komplett neu geschrieben werden. Das alles kostet Zeit und könnte durch Geld unterstützt werden. Das Projekt sucht daher nach Spendern. Die Linux Foundation, die in einer schnellen Reaktion auf den Heartbleed-Fehler Geld für kritische Projekte bereitgestellt hat, wurde laut Beck um Unterstützung gebeten, die bisher aber noch nicht erteilt wurde.
){kind=small}
