Regular-Expression-Denial-of-Service in websocket-extensions

Willkommen zur neuesten Blogserie von Snyk! In dieser monatlichen Serie blickt Snyk auf Schwachstellen zurück, die von unserem Research-Team entdeckt oder gemeldet wurden. Wir wählen eine bemerkenswerte Schwachstelle aus dem vergangenen Monat aus und erzählen die Geschichte ihrer Entdeckung, Erforschung und Offenlegung. Dabei stellen wir die Forschenden, Entwickler und Nutzer vor, die dazu beitragen, Schwachstellen in der Open-Source-Community zu erkennen und zu beheben.

Diese monatliche Serie starten wir diesen Monat mit einer Schwachstelle im Paket websocket-extensions.

Schwachstelle: ReDoS in websocket-extensionsZugewiesene CVEs:CVE-2020-7662, CVE-2020-7663Snyk-Analyst:Sam SanoopEntdeckt von: Robert McLaughlin

Am 2. Juni 2020 veröffentlichte das Snyk Security Research Team eine Schwachstelle vom Typ Regular Expression Denial-of-Service (ReDoS) im beliebten Paket websocket-extensions, von der mehr als 13.000 von Snyk gescannte Projekte betroffen waren. Robert McLaughlin, Doktorand im Fachbereich Informatik an der University of California, Santa Barbara, meldete die Schwachstelle an Snyk. Robert arbeitet im SecLab der UCSB und beschäftigt sich mit der „automatisierten Erkennung und Behebung von Software-Sicherheitslücken“. Bei seiner Untersuchung von ReDoS-Schwachstellen im Node.js-Ökosystem stieß er auf das Problem.

Er erzählte uns, dass er die Schwachstelle zunächst entdeckte, nachdem er eine große Stichprobe regulärer Ausdrücke aus beliebten npm-Paketen zusammengestellt hatte. Das Lab-Team analysierte die gesammelten Beispiele mithilfe von ReDoS-Scannern. Letztlich wurde diese Schwachstelle mit dem Open-Source-Tool RegexStaticAnalysis gefunden, das von Nicolaas Weideman veröffentlicht und gepflegt wird.

Die entdeckte Schwachstelle könnte es einem Angreifer ermöglichen, den Algorithmus für reguläre Ausdrücke anzugreifen. Mit speziell präparierten Eingaben kann der Angreifer ein sogenanntes „katastrophales Backtracking“ auslösen: Dabei muss die RegEx-Engine eine große Zahl möglicher Pfade analysieren, um festzustellen, ob die Zeichenfolge dem RegEx-Muster entspricht. Weitere Informationen zu ReDoS-Schwachstellen finden Sie in diesem Blogbeitrag.

Quelle: Snyk-Bericht „State of Open Source Security“ 2019

Parallel zu seiner Forschung entwickelte Robert einen Proof-of-Concept-Exploit, den er uns bei der Meldung der Schwachstelle zur Verfügung stellte. Sam Sanoop, Analyst im Snyk Security Team, sollte überprüfen, ob sich die Schwachstelle reproduzieren ließ. Mit dem bereitgestellten POC gelang es Sam zunächst jedoch nicht, den Exploit in einem Testcontainer nachzustellen. Robert gab Sam daraufhin weitere Hinweise zur Ausführung des Exploits. Nachdem einige Details der Angriffsnutzlast geklärt waren, konnte Sam bestätigen, dass sich die Schwachstelle tatsächlich reproduzieren ließ.

Sam bestätigte jedoch nicht nur, dass es anfälligen Code gab, sondern überprüfte auch, ob es sich im vorgesehenen Nutzungskontext des Pakets tatsächlich um eine Schwachstelle handelte, die behoben werden musste. Dieser Schritt ist besonders bei ReDoS-Schwachstellen wichtig. Viele in Open-Source-Code verwendete RegEx-Muster wirken bei einer Prüfung möglicherweise anfällig, sind in der Praxis jedoch nicht ausnutzbar.

Nachdem Sam die Gültigkeit, Auswirkungen und Schwere der Schwachstelle bestätigt hatte, untersuchte er die Codebasis des Pakets. Er fand die konkrete Codezeile, durch die die Schwachstelle eingeführt worden war, und erarbeitete eine Anleitung zur Behebung des konkreten Problems im Code. Auf Grundlage dieser Informationen vergab Sam zwei CVEs für die Schwachstelle in den JavaScript- und Ruby-Versionen des Pakets. Außerdem kontaktierte Sam den Melder, bestätigte ihm die Verifizierung der Schwachstelle, teilte ihm die reservierten CVE-Nummern mit und informierte ihn darüber, dass Snyk den Maintainer kontaktieren würde. Anschließend wandte sich Sam an den Maintainer des Pakets und übermittelte ihm die Details der Schwachstelle sowie konkrete Empfehlungen zur Behebung.

In diesem Fall wird websocket-extensions sehr aktiv gepflegt, und der Maintainer reagierte schnell auf die bereitgestellten Informationen. Innerhalb weniger Stunden bestätigte er Sam, dass er die Schwachstelle verstanden hatte und an einer Behebung arbeitete. Sam nannte dem Maintainer die CVE-Nummern, auf die er bei der Veröffentlichung des Fixes verweisen konnte. Gemeinsam legten sie ein Veröffentlichungsdatum für die Schwachstelle fest. Der Maintainer veröffentlichte bereits einen Tag, nachdem Snyk ihn informiert hatte, einen Fix. Die Beschreibungen der Schwachstelle wurden am darauffolgenden Tag veröffentlicht.

Diese Schwachstelle ist ein hervorragendes Beispiel dafür, wie der Offenlegungsprozess von Snyk Forschenden dabei hilft, ihre Entdeckungen zu melden und dafür Anerkennung zu erhalten – und gleichzeitig die Zusammenarbeit mit Open-Source-Maintainern ermöglicht. Robert, der die Schwachstelle gemeldet hatte, erzählte uns, warum er sich für die Offenlegung über Snyk entschieden hat:

„Mein Hauptziel bei der Offenlegung ist die Vergabe einer CVE-Nummer, die Snyk sehr gut handhabt. Ich schätze aber auch, dass Snyk die zuständigen Maintainer kontaktiert und die Behebung koordiniert.“ - Robert McLaughlin

Snyk möchte sicherstellen, dass Schwachstellen valide und ausnutzbar sind, und Maintainer zugleich bei einer verantwortungsvollen Offenlegung unterstützen und ihnen detaillierte Anleitungen zur Behebung bereitstellen. Weitere Informationen zu dieser Schwachstelle oder dazu, wie Sie eine von Ihnen entdeckte Schwachstelle in einem Open-Source-Projekt melden können, finden Sie unter den folgenden Links.

• Schwachstelle melden

• Beschreibung der Schwachstelle (JavaScript)

• Beschreibung der Schwachstelle (Ruby)