[English]In der Software OpenSSL wurde eine Schwachstelle CVE-2023-5363 gefunden. Die Initialisierung der Verschlüsselungsschlüssellänge und des Initialisierungsvektors in OpenSLL ist fehlerhaft. Für die Linux-Distributionen Debian und Ubuntu ist ein Fix aber bereits verfügbar.
Ich bin über nachfolgenden BlueSky-Post auf den Sachverhalt bzw. die OpenSSL-Schwachstelle CVE-2023-5363 aufmerksam geworden.
Das Ganze ist auf cve.mitre.org unter CVE-2023-5363 beschrieben. In OpenSSL wurde ein Fehler bei der Verarbeitung der Längen von Schlüssel und Initialisierungsvektor (IV) festgestellt. Dies kann zu potenziellen Abbrüchen oder Überläufen während der Initialisierung einiger symmetrischer Chiffren führen. Das führt bei einigen Verschlüsselungsmodi zu einem Verlust der Vertraulichkeit.
- Betroffen sind die Chiffren und Verschlüsselungsmodi RC2, RC4, RC5, CCM, GCM und OCB.
- Bei den Verschlüsselungsmodi CCM, GCM und OCB kann das Abschneiden der IV zu einem Verlust der Vertraulichkeit führen.
Sowohl Abbrüche als auch Überläufe des Schlüssels und Überläufe der IV führen zu falschen Ergebnissen und könnten in einigen Fällen eine Speicherausnahme auslösen. Diese Probleme werden jedoch derzeit nicht als sicherheitskritisch eingestuft. Das Ändern der Schlüssel- und/oder IV-Längen wird nicht als üblicher Vorgang angesehen, und die anfällige API wurde erst kürzlich eingeführt.
Darüber hinaus ist es wahrscheinlich, dass die Anwendungsentwickler dieses Problem während der Tests entdeckt haben, schreibt CVE-Mitre, da die Entschlüsselung fehlschlagen würde, wenn nicht beide Peers in der Kommunikation ähnlich verwundbar wären. Aus diesen Gründen gehen die CVE-Mitre-Leute davon aus, dass die Wahrscheinlichkeit, dass eine Anwendung anfällig für dieses Problem ist, recht gering ist.
Sollte eine Anwendung jedoch anfällig sein, wird dieses Problem als sehr ernst eingestuft. Aus diesen Gründen wurde dieses Problem insgesamt als mäßig schwerwiegend eingestuft.
- Die OpenSSL SSL/TLS-Implementierung ist von diesem Problem nicht betroffen.
- Die FIPS-Provider OpenSSL 3.0 und 3.1 sind davon nicht betroffen, da das Problem außerhalb der FIPS-Provider-Grenze liegt.
- OpenSSL 3.1 und 3.0 sind für dieses Problem aber anfällig.
Die CVE-Seite für CVE-2023-5363 gibt weitere Referenzen zu Debian, OpenWall etc. an.
Die eigentliche Frechheit liegt hier verborgen:
„This issue was reported on 21st September 2023 by Tony Battersby of
Cybernetics. The fix was developed by Dr Paul Dale. This problem was
independently reported on the 3rd of December 2022 as part of issue
#19822, but it was not recognised as a security vulnerability at that
time.“ (Quelle: https://www.openssl.org/news/secadv/20231024.txt) „Ist aktuell keine Sicherheitslücke, fassen wir nicht an.“ ist irgendwie grundsätzlich eine schlechte Entscheidung. Das fällt einem immer irgendwann auf die Füße.
Fefe hat dazu in seinem Blog am 2023-10-26 auch einen Kommentar geschrieben.
(https://blog.fefe.de/?ts=9bc48f7a)
@Ralph – richtiger Hinweis. Deckt sich übrigens mit blog.fefe.de. JA, ist fast 1 Jahr alt.
Ich überleg mal provokativ für beide Seiten, Gegen liegen lassen spricht:
o Wir – ich, Du (s.o.) – wollen kein Restrisiko welches auf die Füße fällt
o Anwender wollen sicheres, fehler- +& störungsfreies SSL
o Angreifer mögen abgelehnte „Tickets“ oder Schwachstellen zur Angriffsuche
Entwickler…
o sind imho engagiert, haben jedoch begrenzte Ressourcen
o sind im Vergleich zu Closed Source echt transparent
o müssen jedoch irgendwo priorisieren
o müssen zur Priorisierung auch irgendwie „einstufen“
ist es wirklich eine Frechheit? So etwas kann also passieren. Es zu kritisieren ist legitim – jedoch noch keine Lösung. Ich komme zu einigen Herausforderungen für Entwickler und Anwender:
o Wie kann ich als Anwender handeln – wenn sowas passieren kann?
o Wie verbessere ich den Priorisierungsprozess des Entwicklers?
o Wie untersuche ich Probleme/Tickets besser, tiefer und angemessener?
o Wie stärke ich Open Source, damit sie dazu mehr Ressourcen haben?
o Wie gestaltet man das Sicherheitsniveau folgernd aus operativer Sicht zB für openssl?
Hi…
Ey Günter,
sorry für OT, aber… „Verschlüsselungsschlüssellänge“ – (my) best word today! 😆