OpenSSL-Projekt stellt Sicherheitsleitlinie vor

Das durch den Heartbleed-Bug in die Schlagzeilen geratene OpenSSL-Projekt hat erstmals Richtlinien für seinen Umgang mit Sicherheitslücken veröffentlicht. Darin erläutert es, wie es die Bereitstellung von Sicherheitsfixes handhaben und wen es vor dem Erscheinen eines Updates über Anfälligkeiten informieren will.

Das Projekt teilt Schwachstellen in drei Risikogruppen ein: hoch, mittel und niedrig. Um die Einstufung hoch zu erhalten, muss eine hohe Wahrscheinlichkeit für einen Exploit geläufiger Konfigurationen von OpenSSL bestehen, etwa durch eine Denial-of-Service-Attacke, ein Speicherleck oder Remotecodeausführung. Solche Lücken will das Projekt zunächst geheim halten. Eine Reihe von Linux- und BSD-Distributoren sollen jedoch vorab Informationen und Patches erhalten, damit sie fehlerbereinigte Pakete für ihre Nutzer erstellen und Rückmeldungen geben können.

„Diese [schwerwiegenden] Schwachstellen werden geheim gehalten und ein neues Release aller unterstützter Versionen zur Folge haben“, heißt es in der am 7. September veröffentlichten 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 keinen „Mehrwert“ in Form von Rückmeldungen, Testergebnissen 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, das gleich mehrere solcher Lücken schließt. 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 es sich zu Transparenz hinsichtlich Sicherheitslücken verschrieben habe, sei es entscheidend, dass diese zunächst geheim gehalten würden, bis ein Fix bereitstehe, so das Projekt. „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.“

In der Vergangenheit habe man über Dritte wie CPNI, oCERT oder CERT/CC über Sicherheitslücken informiert, was sich jedoch als ungeeignet herausgestellt habe, so das Projekt weiter. „Es ist im besten Interesse des Internets als Ganzes, Fixes für OpenSSL-Lücken schnellstmöglich herauszubringen. OpenSSL-Embargos sollten in Tagen und Wochen gemsssen werden, nicht in Monaten oder Jahren.“

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 Chris Duckett, ZDNet.com]

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

ZDNet.de Redaktion

Recent Posts

Studie: Ein Drittel aller E-Mails an Unternehmen sind unerwünscht

Der Cybersecurity Report von Hornetsecurity stuft 2,3 Prozent der Inhalte gar als bösartig ein. Die…

3 Tagen ago

HubPhish: Phishing-Kampagne zielt auf europäische Unternehmen

Die Hintermänner haben es auf Zugangsdaten zu Microsoft Azure abgesehen. Die Kampagne ist bis mindestens…

3 Tagen ago

1. Januar 2025: Umstieg auf E-Rechnung im B2B-Geschäftsverkehr

Cloud-Plattform für elektronische Beschaffungsprozesse mit automatisierter Abwicklung elektronischer Rechnungen.

3 Tagen ago

Google schließt schwerwiegende Sicherheitslücken in Chrome 131

Mindestens eine Schwachstelle erlaubt eine Remotecodeausführung. Dem Entdecker zahlt Google eine besonders hohe Belohnung von…

3 Tagen ago

Erreichbarkeit im Weihnachtsurlaub weiterhin hoch

Nur rund die Hälfte schaltet während der Feiertage komplett vom Job ab. Die anderen sind…

4 Tagen ago

Hacker missbrauchen Google Calendar zum Angriff auf Postfächer

Security-Experten von Check Point sind einer neuen Angriffsart auf die Spur gekommen, die E-Mail-Schutzmaßnahmen umgehen…

5 Tagen ago