OpenSSL meldet neue kritische Schwachstelle: Alles zur aktuellen Faktenlage

Das Team vom OpenSSL-Projekt kündigte am 25. Oktober 2022 ein anstehendes Release an (Version 3.0.7), mit dem eine kritische Schwachstelle in OpenSSL adressiert wird. Die Schwachstellen selbst (tatsächlich waren es derer zwei) machte OpenSSL am 1. November 2022 öffentlich, dies begleitet von einem Blog-Artikel mit Details zu den Problemstellungen und möglichen Fixes. Auch wir sind in diesem Blog bereits eingehend auf die Schwachstelle und darauf eingegangen, warum ihr Schweregrad von kritisch auf hoch heruntergestuft wurde. Neben aktuellen Entwicklungen in diesem Zusammenhang beleuchten wir im vorliegenden Artikel nun, wie Sie sich mithilfe von Snyk gegen Schwachstellen wie diese wappnen können.

Zudem haben wir bereits einen Sicherheitshinweis auf Grundlage der derzeitigen Faktenlage veröffentlicht, der bei Verfügbarkeit neuer Details entsprechend aktualisiert wird.

Einzelheiten zur Schwachstelle

Vom Team von OpenSSL-Projekt wurde die Schwachstelle als kritisch eingestuft. Dies jedoch mit dem Hinweis, dass sie sich nur auf Version 3.0 oder höher der Programmbibliothek auswirkt. Demnach sind Sie derzeit also nicht betroffen, wenn Sie OpenSSL in einer älteren Version als 3.0 nutzen.

Mit Blick darauf, welche Schwachstellen in OpenSSL als kritisch einzustufen sind, ist in der Sicherheitsrichtlinie zum Projekt Folgendes zu lesen:

Betroffen sind gängige Konfigurationen und es ist wahrscheinlich, dass diese für einen Exploit anfällig werden, durch den Inhalte etwa aus dem Server-Speicher (z  B. Benutzerdaten) in erheblichem Maße offengelegt werden können. Weitere Beispiele wären Schwachstellen, über die sich Server-Schlüssel bei geringem Aufwand per Remote-Zugriff kompromittieren lassen oder bei deren Exploit eine Remote-Ausführung von Code in gängigen Szenarien als wahrscheinlich gilt. Entsprechende Probleme werden nicht öffentlich gemacht; für alle Versionen, die zum gegenwärtigen Zeitpunkt durch Support abgedeckt sind, wird ein neues Release angesetzt. Wir setzen alles daran, Probleme dieser Art schnellstmöglich zu beheben.

Zu den Hintergründen seiner Entscheidung zur Herabstufung des Schweregrads nimmt OpenSSL in diesem Blog Stellung.

Derzeit sind die anfälligen Versionen von OpenSSL (3.0 oder höher) in Linux-Betriebssystemen wie Ubuntu 22.04 LTS, RHEL 9 und anderen im Einsatz. Linux-Distributionen wie Debian enthalten OpenSSL 3.x jedoch nur in den neuesten Releases, die aktuell noch als Testversionen gelten. Ihr Einsatz in Produktionssystemen dürfte sich daher eher in Grenzen halten. Ebenfalls anfällig sind Container-Images, die auf den betroffenen Linux-Versionen basieren. Allerdings basieren viele populäre Docker-Images aus offiziellen Quellen auf Debian Bullseye (Version 11) und Alpine, die noch OpenSSL 1.x nutzen und somit nicht betroffen sind. Gleiches gilt für offizielle Docker-Container-Images wie nginx und httpd, die häufig zur Verarbeitung von Web-Traffic zum Einsatz kommen: Auch diese Projekte nutzen Bullseye und Alpine und sind daher nicht betroffen.

Betroffen sind zudem Node.js 18.x und 19.x, da Version 3 von OpenSSL3 standardmäßig in diese eingebunden ist. Entsprechende Upgrades sind jedoch bereits auf dem Weg.

Sofern Ihre Entwickler C/C++ nutzen, wäre es aber auch möglich, dass sie Packages von OpenSSL 3.x in Eigenregie in ihren Code eingebunden haben. Daher gilt es, auch diesen Code auf die entsprechenden Packages zu untersuchen.

Von Schwachstellen betroffen oder nicht? So erkennen Sie dies bereits vor ihrer Veröffentlichung

Interessant ist bei dieser Schwachstelle, dass OpenSSL bereits eine Woche vor ihrer Veröffentlichung einen wichtigen Security-Fix ankündigte. Durch den Hinwies darauf, dass mindestens eine kritische Schwachstelle festgestellt wurde, gab man der Nutzer-Community Zeit zur Untersuchung, welche ihrer Anwendungen, Container und Server betroffen sein könnten. Wurden Schwachstellen erst einmal veröffentlicht, ist ihre Erkennung und Behebung mit Security-Tools wie Snyk natürlich ohne Weiteres möglich. Doch bereits vor ihrer Veröffentlichung lässt sich mit Snyk ein Maßnahmenplan für sie ansetzen.

Im Folgenden zeigen wir dies für die OpenSSL-Schwachstelle auf. Das Verfahren ist aber 1-zu-1 auf jede andere Schwachstelle anwendbar, zu der bereits im Vorfeld Details bekannt sind. Voraussetzung ist dabei nur, dass Sie Ihre Software in einer Bill of Materials erfasst haben und Ihre Open-Source-Pakete und Container allesamt einer SCA-Analyse unterziehen.

Kunden der Business- oder Enterprise-Produktvariante von Snyk können auf Anhieb sämtliche Projekte ausmachen, die die anfälligen Versionen 3.0.x von OpenSSL beinhalten. Rufen Sie hierzu Reports auf und navigieren Sie zu Dependencies. Durch Eingabe von openssl im Suchfeld erhalten Sie eine Liste der Projekte, in denen Sie OpenSSL potenziell in Version 3.0.x nutzen. Diese können Sie über die Links unter Projects aufrufen und bei Bedarf auch einen CSV-Export der Daten erstellen.

Im Rahmen der Business- und Enterprise-Varianten ist es zudem möglich, diese Daten mithilfe der Snyk API auszulesen. Das Team von Snyk Labs gibt Ihnen mit snyk-deps-to-csv ein Tool an die Hand, mit dem Sie Ihre Abhängigkeiten in eine CSV-Datei exportieren können. Alternativ können Sie die API hierfür aber auch selbst ansteuern.

Bei Nutzung der kostenlosen wie auch allen anderen Snyk Produktvarianten lässt sich ein Scan auf anfällige OpenSSL-Versionen über das Snyk Dashboard durchführen. Wählen Sie dort einfach ein Projekt aus, klicken Sie auf den Tab „Dependencies“ und geben Sie den Suchbegriff „openssl“ ein. Aus der Liste der OpenSSL-Instanzen können Sie dann die anfällige Version 3.0.x ausmachen.

Ebenfalls möglich ist der Scan Ihrer Projekte über die Snyk CLI:

• Anhand des Befehls snyk test können Sie Ihre Projekte auf Open-Source-Pakete wie OpenSSL sowie auf transitive Abhängigkeiten scannen, die die Bibliothek nutzen. Mit diesem Befehl werden die Ergebnisse direkt in der CLI angezeigt, über snyk monitor erhalten Sie sie in der Snyk Web-UI.

  • Nutzer von C/C++, die Ihr Projekt dahingehend scannen möchten, ob OpenSSL außerhalb eines Package-Managers (also nicht verwaltet) genutzt wird, ergänzen die Option --unmanaged bei Ausführung des Befehls snyk test.

• Container-Images können Sie über den Befehl snyk container test scannen. Auch damit werden die Ergebnisse direkt in der CLI angezeigt. Für ihre Übermittlung an die Snyk Web-UI verwenden Sie snyk container monitor.

• Alle der vorgenannten test-Befehle können Sie um die Option --print-deps ergänzen, um eine Liste der Abhängigkeiten in Ihrer CLI zu erhalten. In Verbindung mit dem Befehl monitor liefert selbige Option die Liste der Abhängigkeiten in der Snyk Web-UI.

• Unter Linux können Sie die bei Ihnen ausgeführte Version von OpenSSL direkt über das Terminal ermitteln. Geben Sie dazu einfach den Befehl openssl version ein, wie im nachfolgenden Screenshot gezeigt.

Ihr Weg zur Mitigierung der neuen OpenSSL-Schwachstelle

1. Machen Sie Ihr Team auf die Bekanntgabe der Schwachstelle und darauf aufmerksam, dass ab Dienstag, 1. November 2022, ein Security-Release dafür verfügbar ist. So sind alle im Bilde und können sich optimal vorbereiten.

2. Setzen Sie von Ihren Anwendungen bis zur Infrastruktur eine umfassende Prüfung dahingehend an, ob oder an welchen Punkten Sie OpenSSL 3.0 oder höher im Einsatz haben.

3. Treffen Sie die nötigen Vorbereitungen zum Update aller anfälligen OpenSSL-Installationen am 1. November 2022.

Falls Sie zur Erkennung und Behebung von Schwachstellen bereits auf Snyk setzen, sind Sie bei Veröffentlichung der Details am 1. November direkt startklar: Die Schwachstelle wird dann umgehend in unserer Datenbank erfasst und beim Scan Ihrer Projekte erkannt. Zudem erhalten Sie für alle von Snyk als anfällig erfassten Versionen eine Benachrichtigung zum Update, sobald entsprechende Fixes verfügbar sind.

Ein Problem zwar, aber kein Grund zur Panik

Kommen kritische Schwachstellen auf, kann sich natürlich leicht Stress einstellen. Nerven zeigen müssen Sie deshalb jedoch nicht. Das OpenSSL-Projekt zeichnet sich seit jeher durch einen verantwortungsvollen Umgang mit Security-Incidents aus, auch im Hinblick auf zeitnahe Fixes.

Außerdem gibt es heute ja auch Tools wie die von Snyk, die Ihnen die Erkennung von Schwachstellen deutlich erleichtern. Sofern Sie sie noch nicht nutzen, dann ist jetzt vielleicht der perfekte Zeitpunkt. Denn damit werden Sie nicht nur über Incidents wie diesen direkt bei Auftreten benachrichtigt, sondern können auch potenziell verfügbare Security-Fixes nahtlos ausrollen.

Ausnahmslos alle Probleme werden Sie zwar auch damit nicht beheben können. Wenn Sie aber über die kritischen im Bilde bleiben und Updates rasch umsetzen, sind Sie bereits deutlich besser aufgestellt, um Risiken zu reduzieren und Incidents vorzubeugen.

Weiterführende Informationen

Im Folgenden noch einige Ressourcen rund um die Schwachstelle, die für die Vorbereitung Ihrer Reaktion nützlich sein könnten:

• Sicherheitshinweis von Snyk

• Docker DSA 2022-0001\: Vorläufiger Hinweis mit Liste der betroffenen Pakete und öffentlichen Container-Images zum ersten Abgleich bis zur CVE-Veröffentlichung

• SANS Internet Storm Center: Liste betroffener Linux-Distributionen

• DistroWatch: Liste betroffener Linux-Distributionen

• Hinweis von Node.js\: Security-Release aufgrund der Nutzung von OpenSSL 3 in Node.js 18.x und v19.x