Neue kritische OpenSSL-Schwachstelle: Was Sie wissen müssen
31. Oktober 2022
0 Min. LesezeitAnmerkung der Redaktion: 1. November 2022
Snyk hat unsere eigenen Systeme und Tools auf die Verwendung von OpenSSL v3 überprüft. Dabei haben wir festgestellt, dass Snyk Broker in den Versionen 4.127.0 bis 4.134.0 eine betroffene Version von OpenSSL 3.0 verwendet und auf Version 4.135.0 oder höher aktualisiert werden sollte. Mit Snyk Broker können Kunden unterstützte interne SCM-Plattformen in Snyk integrieren.
Am 25. Oktober 2022 kündigte das OpenSSL-Projekt ein bevorstehendes Release von OpenSSL (Version 3.0.7) an, das eine kritische Sicherheitslücke beheben soll. Die Schwachstellen (es waren zwei statt einer) wurden am Dienstag, dem 1. November 2022, öffentlich gemacht. Das OpenSSL-Projekt veröffentlichte einen Blogbeitrag mit Einzelheiten zu den Problemen und den Fehlerbehebungen. In einem separaten Blogbeitrag geht Snyk ebenfalls auf die Schwachstellen und die Gründe für ihre Herabstufung von kritisch auf hoch ein. In diesem Blog erfahren Sie, wie Sie sich mit Snyk auf solche Schwachstellen vorbereiten können. Der Beitrag wurde anhand der neuesten Informationen aktualisiert.
Snyk hat eine Sicherheitsmeldung veröffentlicht, die alle derzeit bekannten Details enthält. Sobald neue Informationen öffentlich werden, aktualisieren wir die Meldung.
Über die Schwachstelle
Das OpenSSL-Projekt stuft diese Schwachstelle als kritisch ein, erklärt jedoch, dass OpenSSL-Versionen vor 3.0 nicht betroffen sind. Wenn Sie also eine OpenSSL-Version unter 3.0 verwenden, sind Sie vorerst nicht betroffen.
In der Sicherheitsrichtlinie des OpenSSL-Projekts wird erläutert, was als kritische Schwachstelle gilt:
Betroffen sind gängige Konfigurationen, bei denen die Schwachstellen wahrscheinlich auch ausgenutzt werden können. Beispiele dafür sind die weitreichende Offenlegung von Server-Speicherinhalten (wodurch möglicherweise Benutzerdaten preisgegeben werden), Schwachstellen, die sich aus der Ferne leicht ausnutzen lassen, um private Server-Schlüssel zu kompromittieren, oder Fälle, in denen die Ausführung von Remote-Code unter gängigen Bedingungen als wahrscheinlich gilt. Diese Probleme werden vertraulich behandelt und führen zu einem neuen Release aller unterstützten Versionen. Wir werden versuchen, sie so schnell wie möglich zu beheben.
Weitere Informationen zu den Gründen für die Herabstufung des Schweregrads auf kritisch finden Sie im OpenSSL-Blog.
Die anfälligen OpenSSL-Versionen (3.0 und höher) werden derzeit in Linux-Betriebssystemen wie Ubuntu 22.04 LTS, RHEL 9 und anderen verwendet. Linux-Distributionen wie Debian enthalten OpenSSL 3.x jedoch nur in ihren neuesten Releases, die noch als Testversionen gelten. Daher ist die weitverbreitete Nutzung in Produktionssystemen möglicherweise begrenzt. Auch Container-Images, die mit betroffenen Linux-Versionen erstellt wurden, sind betroffen. Allerdings verwenden viele beliebte offizielle Docker-Images Debian Bullseye (11) und Alpine, die weiterhin OpenSSL 1.x nutzen und nicht betroffen sind. Auch die offiziellen Docker-Container-Images für Projekte wie nginx und httpd, die häufig für die Verarbeitung von Web-Traffic eingesetzt werden, basieren auf Bullseye und Alpine und sind nicht betroffen.
Node.js 18.x und 19.x verwenden standardmäßig ebenfalls OpenSSL 3. Wir rechnen daher in den nächsten Tagen mit Updates für Node.js.
Wenn Ihre Entwicklerinnen und Entwickler C/C++ verwenden, binden sie möglicherweise OpenSSL-v3-Pakete in ihren Code ein. Prüfen Sie diesen Code auf die betreffenden OpenSSL-Pakete.
So finden Sie heraus, ob Sie betroffen sind, bevor Schwachstellen veröffentlicht werden
Interessant an dieser Schwachstelle ist, dass das OpenSSL-Projekt eine Woche vor dem Release eine wichtige Sicherheitskorrektur angekündigt hat. Da bekannt war, dass mindestens eine kritische Schwachstelle vorlag, blieb den Teams Zeit, nach potenziell betroffenen Anwendungen, Containern und Servern zu suchen. Sobald Schwachstellen veröffentlicht sind, erkennen Sicherheitstools wie Snyk sie selbstverständlich und bieten Korrekturen an. Doch wie können wir Snyk nutzen, um einen Plan zu erstellen, bevor eine Schwachstelle veröffentlicht wird?
Die folgenden Schritte beziehen sich auf diese OpenSSL-Schwachstelle. Sie lassen sich jedoch auf jede Schwachstelle anwenden, zu der vorab Details bekannt sind – vorausgesetzt, Sie verfügen über eine Software-Stückliste und führen eine vollständige SCA-Analyse all Ihrer Open-Source-Code-Pakete und Container durch.
Wenn Sie Snyk-Kunde mit einem Business- oder Enterprise-Plan sind, können Sie alle Projekte finden, die anfällige OpenSSL-Versionen (3.0.x) enthalten. Öffnen Sie Berichte und dann Abhängigkeiten. Geben Sie im Suchfeld openssl ein, um zu sehen, wo Sie möglicherweise Versionen von 3.0.x verwenden. Über den Link Projekte gelangen Sie zu den relevanten Projekten. Sie können die Daten bei Bedarf auch als CSV-Datei exportieren.

Kunden mit Zugriff auf die Snyk-APIs (Business- und Enterprise-Pläne) können diese Daten auch über die API extrahieren. Sie können zum Beispiel ein vom Snyk Labs-Team bereitgestelltes Tool namens snyk-deps-to-csv verwenden, um Abhängigkeiten in eine CSV-Datei zu exportieren. Sie können auch direkt auf die Dependencies-API zugreifen.
Alle Snyk-Nutzerinnen und -Nutzer, auch mit kostenlosen Konten, können nach einer anfälligen OpenSSL-Version suchen. Öffnen Sie dazu das Snyk-Dashboard, wählen Sie ein Projekt aus, klicken Sie auf den Tab „Dependencies“ und suchen Sie nach „openssl“. Betroffen sind wie erwähnt OpenSSL-Versionen 3.0.x.

Wenn Sie Ihre Projekte noch nicht mit Snyk getestet haben, können Sie dies mit unserer Snyk CLI tun:
Um Ihre Code-Projekte auf Open-Source-Pakete wie OpenSSL oder auf transitive Abhängigkeiten zu prüfen, die OpenSSL verwenden, führen Sie
snyk testaus, um die Ergebnisse direkt in Ihrer CLI anzuzeigen, odersnyk monitor, um sie in der Snyk-Weboberfläche aufzurufen.Wenn Sie C/C++ verwenden und wissen möchten, ob Ihr Projekt OpenSSL außerhalb eines Paketmanagers (nicht verwaltet) enthält, fügen Sie beim Ausführen von
snyk testdie Option--unmanagedhinzu.
Um Container-Images zu testen, führen Sie
snyk container testaus, um die Ergebnisse direkt in Ihrer CLI anzuzeigen, odersnyk container monitor, um die Ergebnisse an die Snyk-Weboberfläche zu senden.Um bei beiden oben gezeigten Arten von
testdie Abhängigkeitsliste in Ihrer CLI anzuzeigen, fügen Sie die Option--print-depshinzu. Wenn Sie den Befehlmonitorverwenden, werden die Abhängigkeiten automatisch in der Snyk-Weboberfläche angezeigt.Wenn Sie Linux verwenden, können Sie ganz einfach überprüfen, welche OpenSSL-Version bei Ihnen installiert ist. Führen Sie dazu in Ihrem Terminal den Befehl
openssl versionaus:

So mindern Sie das Risiko der neuen OpenSSL-Schwachstelle
Informieren Sie Ihr Team über die Ankündigung der Schwachstelle und das bevorstehende Sicherheits-Release am kommenden Dienstag, dem 1. November 2022. Am besten bereiten Sie sich vor, indem Sie sicherstellen, dass Ihr Team über das Problem und das anstehende Release Bescheid weiß.
Prüfen Sie Ihre Anwendungen und Ihre Infrastruktur, um festzustellen, ob Sie irgendwo OpenSSL 3.0 oder höher verwenden.
Bereiten Sie sich darauf vor, am Dienstag, dem 1. November 2022, alle anfälligen OpenSSL-Installationen zu aktualisieren.
Wenn Sie Snyk verwenden, um Schwachstellen zu erkennen und zu beheben, nehmen wir die Schwachstelle in unsere Datenbank auf und erkennen sie beim Scannen Ihrer Projekte am 1. November 2022, sobald die Details veröffentlicht sind. Sie werden aufgefordert, alle von Snyk erfassten anfälligen Versionen zu aktualisieren, sobald Korrekturen verfügbar sind.
Keine Panik!
Der Umgang mit kritischen Schwachstellen kann belastend sein, aber keine Panik! Das OpenSSL-Projekt hat eine lange Erfolgsbilanz im verantwortungsvollen Umgang mit Sicherheitsvorfällen und der zeitnahen Bereitstellung von Korrekturen.
Wenn Sie noch kein Tool zur Erkennung von Schwachstellen wie Snyk verwenden, ist jetzt vielleicht ein guter Zeitpunkt, eines auszuprobieren. Solche Tools informieren Sie über Vorfälle wie diesen und unterstützen Sie möglicherweise sogar dabei, verfügbare Sicherheitskorrekturen einzuspielen.
Es ist zwar unmöglich, jedes Problem zu beheben, doch wenn Sie kritische Schwachstellen im Blick behalten und schnell Updates einspielen, können Sie Risiken senken und Sicherheitsverletzungen vermeiden.
Weitere Informationen
Diese zusätzlichen Ressourcen zur bevorstehenden Schwachstelle können Ihnen bei der Vorbereitung helfen:
Docker DSA 2022-0001: eine vorläufige Sicherheitsmeldung im Vorfeld der öffentlichen CVE-Veröffentlichung, die eine Liste betroffener Pakete und öffentlicher Container-Images enthält.
SANS Internet Storm Center: eine Liste betroffener Linux-Distributionen
DistroWatch: eine Liste betroffener Linux-Distributionen
Mitteilung von Node.js: das Sicherheits-Release von Node.js mit dem Hinweis, dass Node.js v18.x und v19.x OpenSSL v3 verwenden
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.



