Login
Newsletter
Werbung

Fr, 4. September 2015, 09:04

Software::Security

OpenSSL-Sicherheit im Rückblick

Das OpenSSL-Projekt hat eine Bilanz der Sicherheitslücken der letzten zwölf Monate gezogen. Höhere Sicherheit ist das wichtigste Ziel des Projekts, und die fortlaufende Verbesserung der Code-Qualität soll wesentlich mit dazu beitragen.

Bearbeitungszeit von OpenSSL-Sicherheitslücken 2014-2015

OpenSSL

Bearbeitungszeit von OpenSSL-Sicherheitslücken 2014-2015

Nach dem katastrophalen Fehler »Heartbleed« im April 2014 erhielt OpenSSL Unterstützung durch die neu gegründete Core Infrastructure Initiative der Linux Foundation. So können nun mehrere Vollzeitentwickler an OpenSSL arbeiten. Sie erarbeiteten zunächst einen Projektplan, der die Problembereiche im OpenSSL-Projekt identifizierte und Wege zu ihrer Lösung aufzeigte. Die Verbesserung von OpenSSL ist nun eine kontinuierliche Arbeit.

Emilia Kasper wirft nun einen Blick auf die Sicherheit von OpenSSL in den letzten zwölf Monaten. Während in den letzten zehn Jahren über hundert publizierte und darüber hinaus in aller Stille viele weitere Sicherheitslücken geschlossen wurden, hat das Projekt seit einem Jahr eine öffentlich nachvollziehbare Herangehensweise. Vor einem Jahr schrieb das Projekt den Prozess in einer Sicherheitsrichtlinie fest. Diese wurde laut Kasper strikt eingehalten und hat sich bewährt.

Die Richtlinie teilt Sicherheitslücken in drei Kategorien ein und definiert, wie das Projekt darauf zu reagieren hat. Der Leitgedanke dabei war, dass wichtige Lücken unverzüglich zur Publikation von Updates führen, während weniger wichtige Lücken gebündelt behandelt werden, um für die Benutzer die Zahl der nötigen Updates zu verringern.

Lücken der Kategorie HIGH sind solche, die in normalen Konfigurationen wahrscheinlich für Angriffe genutzt werden können. OpenSSL war im letzten Jahr von vier solcher Lücken betroffen, davon waren zwei Denial-of-Service-Probleme. Solche Lücken führen zur Einstellung aller anderen Arbeiten, bis ein Patch und ein Update veröffentlicht sind. Die Bearbeitung solcher Lücken soll weniger als einen Monat dauern.

Lücken der Kategorie MODERATE betreffen normalerweise nur einen Teil der Benutzer auf signifikante Weise. Ihre Korrektur erfolgt so schnell wie möglich. Sie werden in die nächste Version von OpenSSL eingebracht, die spätestens nach zwei Monaten erscheint. Auf diese Weise können mehrere Korrekturen in einem Update zusammengefasst werden.

Lücken der niedrigsten Kategorie LOW führen in keinem Fall zu einer unmittelbaren Veröffentlichung einer neuen Version von OpenSSL. Sie werden im Wesentlichen wie andere Fehler behandelt und ihre Korrektur wird in den Code aufgenommen, der die nächste Version von OpenSSL bildet.

Die Grafik zeigt die Bearbeitungszeit von OpenSSL-Sicherheitslücken im letzten Jahr. Alle kritischen Lücken wurden im selbst gesteckten Zeitrahmen behandelt. Über die abgemessene Bearbeitungszeit wird laut Kasper in der Gemeinschaft immer wieder debattiert. Die von CERT empfohlene Spanne von 45 Tagen wurde in der Mehrzahl der Fälle eingehalten. Zum Zeitpunkt der Publikation einer Sicherheitslücke stand stets ein Patch oder ein Update von OpenSSL bereit.

Kritisch bei der von OpenSSL gewählten Strategie ist offensichtlich, dass die gemeldeten Sicherheitslücken in ihrer Auswirkung richtig eingeschätzt werden. Dabei sind dem Projekt auch Fehler unterlaufen. So wurde die RSA EXPORT-Lücke zunächst als unwesentlich angesehen und somit einige Zeit verschenkt, bis das Problem als kritisch erkannt wurde. Außerdem wurden in der Eile einiger Updates neue Fehler eingebaut. Das Projekt will dem mit besseren Tests vor Veröffentlichungen und mit kontinuierlicher Integration begegnen.

Ein längerfristiges, aber vielleicht illusorisches Ziel des Projekts ist es, gar keine Sicherheitslücken mehr flicken zu müssen. Noch immer werden zahlreiche Fehler in dem teils sehr alten Code gefunden, aber die Verbesserung der Codequalität ist ein wichtiges Ziel für die nächsten Jahre. Das vergangene Jahr soll dabei als Maßstab dienen, an dem ersichtlich wird, ob Verbesserungen erzielt wurden.

Werbung
Kommentare (Insgesamt: 3 || Alle anzeigen )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung