Schwachstellenmeldung: Was kommt zuerst – die Sicherheitslücke in PHP oder die CVE?

Sicherheitsforscher müssen eine Reihe von Hürden überwinden, bevor eine potenzielle Schwachstelle überhaupt breite Anerkennung findet. Die erste Hürde besteht darin, die Projektverantwortlichen davon zu überzeugen, dass ein Problem vorliegt – selbst wenn sich dies anhand eines funktionierenden Beispiels belegen lässt.

Manchmal ist die Grenze fließend und schwer zu ziehen: Ein anfälliger Ausführungspfad wird als Fehler statt als Sicherheitslücke eingestuft. Auch der umgekehrte Fall ist möglich: Eine gemeldete Schwachstelle wird als Fehler eingestuft, obwohl sie als Angriffsvektor genutzt wurde.

Ein gutes Beispiel ist die Offenlegung einer Schwachstelle, die DeveloperSteve in der PHP-Kernsprache in der Funktion `concat()` nachverfolgt hat: eine Use-After-Free-Schwachstelle. Sie wurde bei einem Capture-the-Flag-Event demonstriert. Das Team meldete das Sicherheitsproblem, doch einige Beiträge später wurde der Bericht als Fehler eingestuft – obwohl die Schwachstelle ausgenutzt worden war.

Vor Kurzem habe ich den CVE-Prozess für den Vorfall mit der dompdf-Bibliothek durchlaufen. Dadurch verlängerte sich der Zeitplan des Vorfalls um weitere sieben Monate. Das hat meine Wertschätzung für die Arbeit, die hinter den Feinheiten einer CVE-Veröffentlichung steckt, noch verstärkt.

Dabei ist wichtig zu bedenken, dass viele Open-Source-Projekte wie dieses von engagierten Menschen betrieben und weiterentwickelt werden. Viele von ihnen arbeiten außerdem Vollzeit und sind bei der Betreuung solcher Großprojekte denselben täglichen Belastungen ausgesetzt wie wir alle.

Werfen wir einen Blick auf den zeitlichen Ablauf des Vorfalls.

Der zeitliche Ablauf der Meldung des dompdf-Vorfalls

Im Rahmen der öffentlichen Offenlegung durch Positive Security im März 2022 wurde auch der zeitliche Ablauf bis zur Offenlegung veröffentlicht.

Die erste Meldung an die Projektverantwortlichen erfolgte im Oktober 2021 über den Prozess auf der Sicherheitsmeldungsseite des Projekts. Nachdem monatelang keine Antwort eingegangen war, versuchte das Team von Positive Security, die Angelegenheit als Fehler im Repository zu eskalieren.

Schließlich wurde nach der öffentlichen Offenlegung der Schwachstelle eine korrigierte Version veröffentlicht. Hinzu kam, dass DeveloperSteve den anfälligen Ausführungspfad ausnutzen konnte, um die Voraussetzungen für eine Reverse Shell zu schaffen. 

Das wird in Snyks eigener Anwendung Snyk-Labs PHP-Goof demonstriert. Sie enthält die ursprüngliche Schwachstelle, auf deren Grundlage DeveloperSteve PHP-bezogene Sicherheitslücken ergänzte.

Anhand der bisherigen Forschungsergebnisse und der Codebeispiele für den Reverse-Shell-Proof-of-Concept konnte DeveloperSteve sieben Monate nach der ursprünglichen Meldung eine CVE für den Vorfall erwirken. 

Den CVE-Prozess verstehen 

Nachdem wir den CVE-Prozess vor Kurzem selbst durchlaufen haben, verstehen und schätzen wir die Arbeit von Sicherheitsforschern bei der Meldung von Schwachstellen jetzt noch besser. 

DeveloperSteve reichte bei Mitre einen CVE-Antrag mit sämtlichen ursprünglichen Forschungsergebnissen ein, der derzeit noch auf weitere Prüfung wartet. Diese Schwachstelle wurde außerdem als Beispiel in die PHP-Goof-Demoanwendung aufgenommen.

In einem aktuellen Beispiel meldete ein Forscher im Januar eine Use-After-Free-Schwachstelle. Sie wurde auf den Schwachstellenseiten von Snyk aufgeführt und als CVE-2021-21708 identifiziert.

Eine CVE beantragen

Zunächst schien der Prozess einfach genug: ein Webformular ausfüllen und warten, bis jemand die Ergebnisse überprüft. Auf der CVE.org-Seite zum Melden und Beantragen stellte DeveloperSteve jedoch fest, dass vor dem Einreichen noch einige Schritte zu erledigen sind. 

Im ersten Schritt muss die CVE-Partnerorganisation ermittelt werden, die zur Reservierung und Veröffentlichung von CVEs für die gemeldete Schwachstelle berechtigt ist. Diese Organisationen werden als CVE Number Authorities (CNA) bezeichnet. 

Eine als CNA gelistete Organisation darf Sicherheitslücken triagieren sowie CVE-Kennungen für gemeldete Sicherheitslücken reservieren und veröffentlichen.

So übernahm Snyk 2021 die Verantwortung für das Schwachstellen-Offenlegungsprogramm des Node.js-Ökosystems. Damit ist Snyk eine CNA und veröffentlicht regelmäßig CVE-Sicherheitsmeldungen für zahlreiche Ökosysteme, etwa npm.

Hinweis: Mit dem einfach auszufüllenden Formular zur Offenlegung von Schwachstellen können Sie Sicherheitslücken melden.

Fazit zur CVE-Meldung

Manchmal ist die Grenze fließend: Ein gemeldeter anfälliger Ausführungspfad wird als Fehler und nicht als Schwachstelle eingestuft. Zudem kann ein gemeldeter Fehler einen anfälligen Ausführungspfad verursachen und somit tatsächlich eine Sicherheitsbedrohung darstellen. 

Nach der ersten Entdeckung eines Sicherheitsfehlers oder Problems durch die Community, einen Sicherheitsforscher oder einen Mitwirkenden folgt die Untersuchungsphase, in der das gemeldete Problem genauer analysiert wird. Angreifer nutzen Fehler häufig als Angriffsvektor, um unerwünschtes Verhalten in eine Anwendung und/oder Infrastruktur einzuschleusen. 

Das Sicherheitsteam von Snyk setzt sich dafür ein, Sicherheitslücken aufzudecken, sobald sie erstmals als Fehler gemeldet werden – noch bevor sie offiziell als CVEs veröffentlicht werden. Dieses Engagement von Snyk trägt dazu bei, unsere Nutzer so früh wie möglich zu schützen und zu informieren.