[English]Kleiner Vorab-Hinweis für Nutzer von OpenSSL – es gibt wohl eine Schwachstelle in der Implementierung dieser Software. Nun hat das Team der OpenSLL-Entwickler angekündigt, dass man zum 1. November 2022 ein Update auf die Version 3.0.7 veröffentlichen werde. Nun wird spekuliert, dass dies auch den Fix für eine OpenSLL-Schwachstelle beinhaltet und wie kritisch das Ganze wird.
Anzeige
Was ist OpenSSL?
OpenSSL ist eine weit verbreitete Code-Bibliothek, die eine sichere Kommunikation über das Internet ermöglicht. OpenSSL umfasst Implementierungen der Netzwerkprotokolle und verschiedener Verschlüsselungen sowie das Programm openssl für die Kommandozeile zum Beantragen, Erzeugen und Verwalten von Zertifikaten (siehe). Wer im Internet surft, eine Website besucht oder auf einen Online-Dienst zugreift, nutzt OpenSSL.
OpenSSL 3.0.7 kommt
Mir ist der Hinweise von mehreren Seiten zugegangen, sowohl von den Sicherheitsexperten von Check Point als auch auf Twitter sowie von Blog-Leser Timo W. (danke dafür). Timo schrieb:
Hallo Günter,
folgendes wäre möglicherweise eine Erwähnung in deinem Blog wert.
Am 01.11 soll ein Fix für eine ziemlich kritische OpenSSL Schwachstelle erscheinen. (3.0.7)
Diese betrifft wohl alle OpenSSL Versionen ab Version 3. Patching wird dringenst zeitnah empfohlen.
Siehe beispielsweise:
Wichtige Sicherheitspatches für OpenSSL in Sicht | heise online
oder auch
In der Mitteilung des OpenSLL-Teams wird von einem Sicherheitsfix gesprochen, ohne Details offen zu legen. Das Update soll am Dienstag, den 1. November 2022 (am späteren Nachmittag) freigegeben werden.
War das was?
Und nun wird es spannend. Die Entwickler schreiben, dass OpenSSL 3.0.7 Fixes für eine Schwachstelle enthält, die mit dem höchsten Schweregrad Critical gekennzeichnet ist. Dazu schreiben die Leute von Check Point:
Anzeige
In einer offiziellen Erklärung vom vergangenen Dienstag kündigte das OpenSSL-Projektteam die bevorstehende Veröffentlichung der nächsten Version an, die am Dienstag, den 1. November, erscheinen wird. Es wird erwartet, dass diese Version 3.0.7 einen Fix für eine kritische Sicherheitslücke enthält. Während genaue Details der Sicherheitslücke zu diesem Zeitpunkt noch unbekannt sind, rufen wir Organisationen dazu auf, die Veröffentlichung aufmerksam zu verfolgen, ihre Systeme mit Patches zu versehen und alle Schutzmaßnahmen auf dem neuesten Stand zu halten, bis weitere Details bekannt werden.
Interessant ist aber der Tweet von Will Dormann vom 28. Oktober 2022, der davon ausgeht, dass ein praktisch nicht wie z.B. Heartbleed ausnutzbarer Speicherfehler gepatcht werden dürfte.
Die Frage ist dann, wie weitreichend das Sicherheitsproblem ist. Mal abwarten, ob am 1. November 2022 plötzlich alle möglichen Betriebssystem- und Software-Updates anstehen. Denn als Endanwender kann man eh wenig tun – die OpenSSL-Bibliothek steckt ja in Produkten. Wenn ich dann sehe, wie schlecht der Patchstand – speziell bei IoT-Geräten oder Android-Smartphones – ist, wird deutlich, auf welcher Rasierklinge die gesamte Branche reitet. Es ist ein Unding, wenn durch solche Geschichten Milliarden Geräte wegen fehlender Patches sicherheitstechnik zum Elektronik-Schrott werden. Im Grunde müsste es (alleine aus Gründen der Nachhaltigkeit) eine Verpflichtung der Hersteller für Patches über die Lebensdauer der Geräte geben.
Ergänzung: In der Tanium-Community gibt es den Beitrag How Tanium Can Help Identify OpenSSL 3.0.X, in dem noch einige Überlegungen angestellt werden – genaueres werden wir aber erst wissen, wenn die Details zur Schwachstelle öffentlich sind.
Ergänzung 2: OpenSSL 3.0.7 ist veröffentlicht – siehe OpenSSL 3.0.7 mit Sicherheitsfix verfügbar.
Anzeige
Interessant ist vor allem dass man von einem kritischen Fehler spricht, diesen aber nicht offenlegt. Security through obscurity war aber noch nie ein valides Konzept und sorgt, wie auch in diesem Fall, nur für den Verlust von Vertrauen.
Die Details werden wahrscheinlich später veröffentlicht, wenn die Patches draußen sind und genügend Zeit zum Patchen bestand, sodass die Lücke vorher nicht ausgenutzt werden kann.
https://de.wikipedia.org/wiki/Responsible_Disclosure_(IT-Sicherheit)
warum sollte man die details vor erscheinen des fixes veröffentlichen?
um einen angriff auf die noch nicht gepatchte version zu erleichtern?
Wenn eine kritische Schwachstelle für ein Programm bekannt ist, dann wird dieses Programm solange blockiert, bis diese geschlossen ist. Gerade dann wenn ich nicht verifzieren kann was das Problem ist. Wenn die Schwachstellenart bekannt ist, dann kann man entsprechend alternative remediation Möglichkeiten in Betracht ziehen, so eben nicht und da ist der Schaden dann meist größer.
Das Argument des erleichterten Angriffs gilt also nicht, denn wer keine Maßnahmen ergreift, hat selber schuld und handelt grob fahrlässig.
Warum sollte man diesen offenlegen bevor dieser gepatcht wurde? Ist doch gängige Praxis…
Es handelt sich hierbei vor allen um ein responsible disclosure-Verfahren, bei dem der Hersteller von OpenSSL mit Herstellern von Betriebssysteme und kritischer Infrastruktur zusammenarbeitet, um einen geimeinsame Veröffentlichung der Patches hinzubekommen. Der genaue Fehler wird i.d.R. zu dem Zeitpunkt ebenfalls veröffentlicht.
Wenn es eine trivial ausnutzbare Lücke sein sollte lässt sich aus der Veröffentlichung der entsprechenden Patches auch sehr leicht ein Exploit generieren. Durch die abgestimmte Veröffentlichung können Anwender und sonstige Hersteller sich zumindest auf einen entsprechenden Termin einstellen und zeitnah ihre System aktualisieren.
PS: Der gesamte Quellcode von OpenSSL ist als OpenSource veröffentlicht.
Den werden sie schon noch offenlegen, aber erst nachdem der Patch raus ist. Ist ja alles Open Source.
Wenn ich mich recht erinnere, dann existiert das Problem nur in der 3er-Version von OpenSSL, wurde also mit ihr oder einer 3.0.x-Version eingeführt.
So weit verbreitet ist diese 3er-Version im IoT-Bereich und Embedded-Bereich wahrscheinlich noch nicht, und falls sie doch in dem einen oder anderen Gerät zum Einsatz kommen sollte, stehen die Chancen nicht schlecht, dass ein Patch veröffentlicht wird. Aber 100%ig sicher ist das leider nicht.
Security by obscurity kann man so sehen – Fefe meckerte auch schon :-) https://blog.fefe.de/?mon=202210
Transparenz und wenig Obscurity ist wohl immer begrüßenswert – möchte trotzdem einen Gedanken anstossen, um dies zu relativieren:
Nach wieviel Zeit fängt "Obscurity" an – zB hier bei Opensource oder kostenlos? 6 Stunden? 1 day, 5, 20 days? Pauschal hier nach Obscurity einzuordnen fällt mir schwer – hängt zB auch vom Sachverhalt, Impact o. Releasereichweiten und dem was kommuniziert wurde ab:
– 12.10. Deprecated 1.1.1r/3.06 https://www.openssl.org/news/newslog.html
(Sehe ich als: "Irgendetwas stimmt nicht mit aktuellem Release")
(Bewerte ich als: Richtig – muss zurück in die Küche)
– 22.10. Awareness/Alert: https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html
(Verstehe ich als "Müssen wir wohl neu machen" – Ursache offen )
– 01.11. Announced Solution (1 week +)
Und was wäre mit der Welt, wenn über Nacht ALLE SSL-Services kompromittierbar wären? Wenn es keine Mitigation ausser Abschalten gibt? Hier bewegen wir uns wohl im Notfallmanagement… Welche Lösung & Kommunikation wünschen wir uns? Fix in 10-20 Tagen und vorher kommunizieren wie es auszunutzen geht – auch OHNE Mitigation?
Worauf ich hinaus will: Auch hier gibt es eine Grauzone, eine Latenz, jede Menge Managementdefizite und sicher viele uU organisatorische Maßnahmen:
Und da hätt ich für Openssl noch Verständnis und viel Sympathie – MS und einige Riesen reissen hier extrem tiefere Lücken.
Im öffentl. Dienst habe ich einmal miterlebt, wie man alleine 3 Monate brauchte, um zu definieren WAS ein Notfall bei solchen Sachverhalten ist , WER dann den "Abschalt-Entscheiderhut" aufhaben darf und viel wichtiger: WER Schuld hat …
Es gibt übrigens nette technisch-organisatorische Maßnahmen um singuläre POFs wie SSL abzufedern, nur eine SSL-Beispielthese: SSL gehört mE zB als "Service-frontend zwecks Login" (standalone und unmanaged) nicht umbedingt nackt ans Netz. Wär eine Kolummne für sich – jedoch eh nicht für selten gepatchte IoTs oder Missmanagement: Denn für Nutzung unter hoher Kritikalität wären für den Nutzer weitere ToMs sogar rechtlich eher zwingend.
Sind wir also gespannt, was genau die Version "r" zurückholte – oder ob NUR Release 1r/06 betroffen war… ;-) Hat jemand vll. Feedback aus internen SSL-Kreisen?
So lang glaub ich an das Gute im Menschen (*seufz*),
JA! Ich will ab und an noch ans Gute glauben…
Weiß den jemand vielleicht grob, was überhaupt OpenSSL Version 3.0 und höher nutzt? Windows 10 oder 11? Android 11 oder 12? Fritzboxen? Welche Linuxversionen, etc.? Welche Browser? Oder sind wir alle da blind und müssen einfach abwarten?
OpenVPN
Laut der Download-Seite bei OpenVPN unterstützt selbst die 2.5.7 OpenSSL 3 noch nicht vollständig, zumindest steht es dort so. Erst ab Version OpenVPN 2.6 soll die Version OpenSSL 3 voll unterstützt werden. Das wäre echt schlechte und missverständliche Kommunikation, wenn in den Binärpaketen für Windows bereits die 3er-Version enthalten ist. In der 2.5.6 wird jedenfalls noch von OpenSSL 1.1.1o geredet.