Heartbleed-Bug: OpenSSL-Projekt reagiert mit Sicherheitsleitlinie

Das im April durch den Heartbleed-Bug in die Schlagzeilen geratene OpenSSL-Projekt hat nun Richtlinien für den Umgang mit Sicherheitslücken veröffentlicht. Die Entwicklern erläutern damit erstmals, wie sie die Bereitstellung von Sicherheitsfixes handhaben und wen sie vor dem Erscheinen eines Updates über Anfälligkeiten informieren wollen.

Schwachstellen teilt das Projekt nun in drei Risikogruppen ein: hoch, mittel und niedrig. Für die Einstufung “hoch”, muss die Wahrscheinlichkeit für einen Exploit geläufiger Konfigurationen von OpenSSL, etwa durch eine Denial-of-Service-Attacke, ein Speicherleck oder Remotecodeausführung, hoch sein. Solche Schwachstellen will das Projekt künftig geheim halten. Eine Reihe von Linux- und BSD-Distributoren sollen Informationen und Patches jedoch vorab erhalten. Sie können so fehlerbereinigte Pakete für ihre Nutzer erstellen und Rückmeldungen geben.

“Diese [schwerwiegenden] Schwachstellen werden geheim gehalten und ein neues Release aller unterstützter Versionen zur Folge haben”, heißt es in der Sicherheitsrichtlinie. “Wir werden versuchen, die Zeit, die diese Lücken unter Verschluss bleiben, so kurz wie möglich zu halten; unser Ziel ist maximal ein Monat, wenn wir es unter Kontrolle haben, und bedeutend schneller, wenn ein bedeutendes Risiko besteht oder wir davon Kenntnis haben, dass der Fehler ausgenutzt wird.”

Sollte ein Distributor Schwachstellen durchsickern lassen oder keinerlei Rückmeldungen, Testergebnisse oder Korrekturen liefern, behält sich das OpenSSL-Projekt vor, ihn bei künftigen Problemen nicht mehr vorab zu informieren. Mittelschwere Anfälligkeiten sollen zunächst ebenfalls geheim gehalten und mit dem nächsten OpenSSL-Release beseitigt werden.

Schwachstellen, von denen ein niedriges Risiko ausgeht, will das Projekt direkt im Entwicklungszweig beheben und möglicherweise auch in älteren unterstützten Versionen von OpenSSL schließen. Sie sind aber kein Grund für ein neues Release, wie es in den Richtlinien heißt.

Auch wenn man sich der Transparenz in Bezug auf Sicherheitslücken verpflichtet fühle, sei es entscheidend, diese geheim zu halten, bis ein Fix bereitsteht. “Je mehr Leute man im Voraus darüber informiert, desto größer ist die Wahrscheinlichkeit, dass es zu einem Leak kommt. Wir haben dies schon zuvor beobachtet, sowohl bei OpenSSL als auch bei anderen Projekten.”

Das Konzept, dass Nutzer gegen Zahlung vorzeitig über Sicherheitslücken informiert werden, hat das Projekt verworfen. “Es ist nicht akzeptabel, dass Organisationen vorzeitige Informationen zu Marketingzwecken und als Wettbewerbsvorteil einsetzen. Wir glauben fest daran, dass das Recht, über Patches informiert zu weden, in keiner Weise davon abhängen soll, zahlendes Mitglied irgendeines Forums zu sein.

[mit Material von Björn Greif, ZDNet.de]

Tipp: Wie sicher sind Sie bei der Sicherheit? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de