Regular Expression Denial-of-Service in websocket-extensions
Welcome to the newest Snyk blog series! In this monthly series, Snyk looks back on the vulnerabilities discovered by or reported to our research team. We choose one noteworthy vulnerability from the past month and tell the story behind the discovery, research, and disclosure of the vulnerability. We highlight the researchers, developers, and users who are helping identify and remediate vulnerabilities across the open source community.
We’re kicking off this monthly series this month with a vulnerability discovered in the websocket-extensions package.
Vulnerability: ReDoS in websocket-extensions
CVEs assigned: CVE-2020-7662, CVE-2020-7663
Snyk Analyst: Sam Sanoop
Discovered by: Robert McLaughlin
On June 2, 2020, the Snyk Security Research Team published a Regular Expression Denial-of-Service (ReDoS) vulnerability identified in the popular websocket-extensions package affecting over 13,000 projects scanned by Snyk. The vulnerability was reported to Snyk by Robert McLaughlin, a Ph.D. student in the Computer Science program at the University of California, Santa Barbara. Robert works in UCSB’s SecLab and focuses on “automated detection and repair of software security vulnerabilities”. Robert was researching ReDoS vulnerabilities across the Node.js ecosystem when he identified the issue.
He told us he initially discovered the vulnerability after collecting a large sample of regular expressions from popular npm packages. The lab team used ReDoS scanners to analyze the samples that had been gathered. Ultimately, this particular vulnerability was identified using the open source RegexStaticAnalysis tool published and maintained by Nicolaas Weideman.
The vulnerability identified could allow a malicious user to attack the regular expression algorithm. By supplying specifically crafted input, the attacker can force a situation known as “catastrophic backtracking” where the RegEx state engine has to analyze a high number of potential paths in order to determine the string matches the RegEx pattern. You can read more about ReDoS vulnerabilities in this blog.
Along with his research, Robert developed a proof-of-concept exploit that he provided as part of reporting the vulnerability to us. Sam Sanoop, an analyst on the Snyk Security Team, was tasked with validating the reproducibility of the vulnerability. However, Sam initially was not able to reproduce the exploit in a test container using the supplied POC. However, Robert was able to provide Sam additional guidance for how to launch the exploit and after clarifying some of the details of the attack payload, Sam was able to confirm that the vulnerability was indeed reproducible.
However, beyond simply confirming that vulnerable code exists, Sam also verified that within the context of the package (i.e. how the package is intended to be used), this was truly a vulnerability that would require remediation. This step is particularly important when working with ReDoS vulnerabilities. There are many RegEx patterns used in open source code that upon reviewing the could be vulnerable but, in reality, are not exploitable.
Having confirmed the validity, impact, and severity of the vulnerability, Sam then investigated the code base for the package. He located the actual line of code that introduced the vulnerability and developed guidance on how to remediate the specific issue that he found in the code. Armed with this information, Sam assigned two CVE’s to describe the vulnerability in both the JavaScript and Ruby versions of the package. Sam also contacted the reporter to confirm that the vulnerability was verified, share the CVE numbers that were being reserved, and inform him that Snyk would be contacting the maintainer. Sam at that point also reached out to the package’s maintainer and provided him with the details of the vulnerability as well as the specific recommendations for how he could implement a fix.
In this case, websocket-extensions is a very actively maintained package and the maintainer was very responsive to the information provided. Within a couple of hours, he responded back to Sam confirming that he understood the vulnerability and that he was working on a fix. Sam provided the maintainer with the CVE numbers that he could reference when releasing his fix and they agreed on a publication date for the vulnerability. The maintainer was able to release a fix for the vulnerability within a day of Snyk reporting it to him and the vulnerability write-ups were published the following day.
This vulnerability is a terrific example of how Snyk’s disclosure process helps researchers report and receive credit for their discoveries while also working collaboratively with open source maintainers. Robert, the researcher who reported this vulnerability, talked to us about why he chose to disclose through Snyk:
“My main goal in disclosure is CVE assignment, which Snyk handles quite well. But I also appreciate that Snyk will contact the appropriate maintainers and coordinate a fix.”
-Robert McLaughlin
Snyk’s goal is to ensure the validity and exploitability of the vulnerabilities while providing maintainers with responsible disclosure and detailed guidance for fixing their vulnerabilities. For more information on this vulnerability or how to report a vulnerability you’ve discovered in an open source project, see the links below.
