Fedora Linux 37 verspätet sich weiter. Der 1. Termin am 18. Oktober konnte wegen einiger Fehler nicht gehalten werden, auch der 2. Release-Termin am 1. November wird nicht wahrgenommen werden. Jetzt ist der 15. November als neuer Termin festgelegt. Vor Jahren kamen Verspätungen bei Fedora häufig vor, das hat sich aber in den letzten Jahren stark verbessert. Und an der jetzigen Verschiebung ist Fedora nicht schuld.
Kritische Lücke in OpenSSL
Wie dem Fedora Magazine zu entnehmen ist, erscheint am 1. November ein Update für OpenSSL in Version 3.0.7, das eine kritische Sicherheitslücke behebt. Die Ankündigung auf der OpenSSL-Liste fällt denkbar knapp aus. Da die Interna zu dieser Sicherheitslücke und deren Behebung ebenfalls erst am 1. November bekannt werden, entschied das Fedora Steuerungskomitee (FESCo), die Veröffentlichung um zwei Wochen zu verschieben.
Das Red Hat Security Team riet zu der Verschiebung, um mit Fedora Linux 37 nicht ein Paket mit einer in ihren Ausmaßen unbekannten kritischen Lücke zu veröffentlichen und die Verantwortung auf die Anwender abzuwälzen, die sich dann um eine zeitnahe Aktualisierung kümmern müssten.
Richtige Entscheidung
OpenSSL ist ein wichtiger Dreh- und Angelpunkt, wenn es um die Implementierung von Transport Layer Security für Website- und E-Mail-Verschlüsselung geht. Die letzte als kritisch eingestufte Lücke in OpenSSL stammt aus dem Jahr 2014 und ist uns allen noch als Heartbleed in Erinnerung. Sollte die jetzt geschlossene Lücke eine ähnliche Dimension haben, so ist die Entscheidung von FESCo die einzig Richtige.
Oft werden in solchen Fällen Details von Lücken mit Entwicklern geteilt, sodass diese ihre Veröffentlichungen anpassen können. Da Fedoras Entwicklungs-Pipelines aber alle offen sind, würden jetzt eingepflegte Fixes die Lücke offenlegen und deren Ausbeutung ermöglichen.
Fedora Programm-Manager Ben Cotton schreibt, die Go/No-Go-Sitzung sei »lebhaft« gewesen und nicht alle Teilnehmer seien mit der Entscheidung einverstanden gewesen. Immerhin gibt die Verschiebung den Entwicklern auch mehr Zeit, sich um zwei Blocker-Bugs zu kümmern, die noch offen sind.
Ich finde es unverantwortlich informationen zu solchen Bugs mit Ansage zurückzuhalten.
Begründung?
Weil verantwortungsbewuste Organisationen, Unternehmen oder Personen Dinge kurzfristig umbiegen, oder Teile deaktivieren könnten. Vielleicht sind auch einige garnicht betroffen, wer weiß das schon… Wenn einige Entwicker den Bug gefunden haben, können auch schon vorher Cracker oder jeder Geheimdienst haben. Ist schon ziemlich schlecht. Und wenn jetzt das Argument kommt: “mit Transparenz kann es besser ausgenutzt werden”, dass wird auch “security by obscurity” genannt.
“Eine eurer Kernkomponenten ist kaputt, wir sagen aber nicht was, wartet auf den nächsten Patchday!!!11”
Es ist unverantwortlich so etwas hinter dem Berg zu halten.
Natürlich gibt es ein gewisses Risiko, dass die Lücke bereits von anderen gefunden wurde. Allerdings kann man sich sicher sein, dass solche Schwachstellen nach einer Veröffentlichung im großen Stil ausgenutzt werden. Und wenn dann noch kein Patch verfügbar ist, ist das einfach schlecht.
Und es ist IMHO auch nicht realistisch zu erwarten, dass Admins da kurz mal selbst Hand anlegen. Womöglich dauert es schon eine ganze Weile überhaupt mal festzustellen, inwiefern man genau betroffen ist, OpenSSL steckt schließlich überall drin, und dann wird auch kein ITler ungefragt die halbe Firmen-IT abschalten, weil er das vielleicht für die sicherste Lösung hält.
Am Ende sind die zu erwartenden Schäden so einfach sehr viel kleiner, falls es überhaupt welche gibt. Ganz generell ist es auch einfach so, dass Zero-Days für die breite Masse nicht das Problem sind, sondern eher die Zeit zwischen der Veröffentlichung einer Sicherheitslücke und der Installation des nötigen Patches, was aus den verschiedensten Gründen oft auch nicht umgehend passiert. Da entstehen die großen Schäden.