Update: OpenSSL-Sicherheitslücken mit hohem Schweregrad

Artikel von

3. November 2022

0 Min. Lesezeit

OpenSSL hat zwei Sicherheitslücken mit hohem Schweregrad veröffentlicht – CVE-2022-3602 und CVE-2022-3786 –, die mit einem Pufferüberlauf zusammenhängen. OpenSSL stufte CVE-2022-3602 zunächst als kritisch ein. Nach eingehender Prüfung wurde der Schweregrad jedoch auf „hoch“ herabgesetzt.

Was ist ein Pufferüberlauf?

Ein Pufferüberlauf ist eine bestimmte Art von Laufzeitfehler, bei dem ein Programm über das Ende eines Puffers oder Arrays hinaus schreibt und benachbarten Speicher überschreibt – daher die Bezeichnung „Überlauf“. Anders als die meisten Fehler tritt ein Pufferüberlauf nicht bei jeder Programmausführung auf. Stattdessen müssen bestimmte Bedingungen erfüllt sein, etwa eine unerwartete Benutzereingabe, damit die Sicherheitslücke ausgelöst wird.

Beide Sicherheitslücken mit hohem Schweregrad werden bei der Prüfung von Namensbeschränkungen während der Verifizierung von X.509-Zertifikaten ausgenutzt.

4-Byte-Pufferüberlauf bei X.509-E-Mail-Adressen (CVE-2022-3602)
Pufferüberlauf variabler Länge bei X.509-E-Mail-Adressen (CVE-2022-3786)

Die Sicherheitslücke kann auf einem TLS-Client ausgelöst werden, indem eine Verbindung zu einem bösartigen Server hergestellt wird. Sie kann auch auf einem TLS-Server ausgelöst werden, wenn sich ein bösartiger Client verbindet, während der Server eine Client-Authentifizierung anfordert.

OpenSSL Version 3.0.7 wurde als Open-Source-Toolkit für SSL/TLS veröffentlicht. Jedes OpenSSL-3.0-Programm sollte als unsicher und für Angriffe anfällig betrachtet werden, wenn es X.509-Zertifikate aus nicht vertrauenswürdigen Quellen prüft.

Die TLS-Client-Authentifizierung sollte auf Clients und Servern deaktiviert werden, bis das Upgrade installiert wurde.

Betroffene Versionen

Die OpenSSL-Versionen 3.0.0 bis 3.0.6 sind von diesem Problem betroffen.

Nicht betroffene Versionen

1.1.1
1.1.0
1.0.2
1.0.1
1.0.0
0.9.x
fips

Auswirkungen

Denial-of-Service-Angriff
Remote-Code-Ausführung

Wie kann Snyk helfen?

Snyk Open Source

Nachdem die Details zur Sicherheitslücke veröffentlicht wurden, weisen Snyk Open Source-Projekte die Sicherheitslücke beim nächsten erneuten Test aus. Bei Projekten, für die tägliche Tests konfiguriert sind, geschieht dies innerhalb der nächsten 24 Stunden. Natürlich können Sie bei kritischen Projekten auch manuell erneute Tests auslösen, um diese Ergebnisse früher zu erhalten.

Sie können Open-Source-Code auch mit dem Befehl `snyk test` über die Snyk CLI scannen.

Snyk Container

Wird eine Sicherheitsmeldung wie die zu OpenSSL CVE veröffentlicht, muss der Maintainer jeder Linux-Distribution den Sachverhalt prüfen und eine eigene Sicherheitsmeldung herausgeben. Diese Meldung der Distribution löst die Erkennungen in Snyk Container aus. Daher kann es zwischen der OpenSSL-Sicherheitsmeldung und den ersten Erkennungen in Snyk Container zu einer Verzögerung kommen. Wie lange sie dauert, hängt davon ab, wie schnell die Maintainer der Linux-Distributionen ihre Meldungen veröffentlichen. Erfahren Sie in unserem Beitrag zur Vereinfachung der Container-Sicherheit mehr darüber, wie dieser Prozess funktioniert.

Sobald dies geschehen ist, werden diese Erkennungen in den Testergebnissen von Snyk Container angezeigt. Sowohl für Snyk Open Source als auch für Snyk Container werden die Ergebnisse aufgrund der bestehenden Datenverzögerung bis zu 9 Stunden nach Erfüllung der oben genannten Bedingungen in den Berichten angezeigt. Bei Verwendung der Beta-Berichte zum Anzeigen von Problemen kann diese Verzögerung kürzer sein.

Empfehlungen

Nutzer von OpenSSL 3.0 sollten auf OpenSSL 3.0.7 aktualisieren.
Schutz vor Stack-Überläufen

Update zu den Daten für Ubuntu-Sicherheitsmeldungen in der Snyk VulnDB

Referenzen

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.

Jetzt ansehen