Korrekturupdates der kryptografischen Bibliothek OpenSSL 3.0.16, 3.1.8, 3.2.4, 3.3.3 und 3.4.1 sind verfügbar. In den Versionen 3.2.4, 3.3.3 und 3.4.1 wurde eine Schwachstelle (CVE-2024-12797) behoben, die als hochriskant eingestuft wurde. Diese Schwachstelle ermöglicht einen MITM-Angriff auf TLS- und DTLS-Verbindungen. Das Problem tritt nur in Systemen auf, die zur Client-Authentifizierung Raw Public Keys (RPK, RFC 7250) verwenden. Standardmäßig ist die Unterstützung von RPK auf der Clientseite deaktiviert und Server.
Die Schwachstelle tritt auf, da OpenSSL dem Client bei der Herstellung einer Verbindung im SSL_VERIFY_PEER-Verfahren keine Informationen über den Authentifizierungsfehler des Servers zurückgibt, da der Aushandlungsprozess der Verbindung nicht ordnungsgemäß beendet wird. Ein Angreifer kann einen MITM-Angriff durchführen und den Datenverkehr auf seinen eigenen Host umleiten, anstatt zum Zielserver, wobei der Client keine Informationen erhält, dass Server er nicht authentifiziert ist. Das Problem tritt ab der OpenSSL-Version 3.2 auf, in der die Möglichkeit eingeführt wurde, RPK anstelle von X.509-Zertifikaten zu verwenden.
Darüber hinaus wurde in den Updates von OpenSSL die Schwachstelle CVE-2024-13176 behoben, die einen Angreifer in die Lage versetzt, über Seitenkanäle einen ECDSA-privaten Schlüssel zu rekonstruieren, indem er die Verzögerungen analysiert, die beim Erzeugen einer digitalen Signatur auftreten. Das Wesen der Schwachstelle besteht darin, dass für bestimmte elliptische Kurven, z. B. NIST P-521, Berechnungen mit Null-High-Bytes des invertierten Werts des Initialisierungsvektors (Nonce) aus der Gesamtmenge herausgefiltert werden können, deren Verarbeitungszeit sich um 300 Nanosekunden unterscheidet.
Im Fall von ECDSA reicht es aus, sogar nur wenige Bits mit Informationen über den Initialisierungsvektor zu bestimmen, um einen Angriff zur sequenziellen Wiederherstellung des gesamten privaten Schlüssels durchzuführen. Für einen erfolgreichen Angriff muss der Angreifer Zugriff auf das lokale System haben, auf dem die Anwendung läuft, die digitale Signaturen erstellt, oder einen Hochgeschwindigkeitsnetzwerkzugang zur Anwendung mit sehr geringen Latenzen. Der Angreifer muss zudem in der Lage sein, die Generierungszeiten einer großen Anzahl von digitalen Signaturen, die über ihm bekannte Daten erstellt wurden, sehr genau zu analysieren.
Quelle: opennet.ru
