Summer is well underway and our Data Security Research team has been hard at work. Ax is back with us once again, after his video vacation last month. Welcome back, Ax. This month we will cover a Regular Expression vulnerability leading to Denial of Service (ReDoS).
What makes regex-based matching attractive to developers is its efficiency and ease of use when it comes to string matching and filtering operations. However, because regex makes multiple pathways possible for achieving the same outcome, even the slightest mistake in an expression opens up the potential for that particular expression to cause a security vulnerability.
ReDoS vulnerabilities commonly occur when the regular expression being used to evaluate a string doesn’t take into account the possibility of large sized inputs. In the event that the input string is enormously large, the regex matching engine may consume a large amount of CPU resources. If a skilled attacker can repeat this process several times, a DoS condition will occur on the target host, all because of a string matching operation taking up all available memory.
Name of Vuln/Sonatype ID: CVE-2018-1109 aka SONATYPE-2018-0081
Type of Vulnerability: Denial of Service attack
Components Affected: npm braces: [2.2.0,2.3.1)
Vulnerability Description:
The `braces` component is vulnerable to a Regular expression Denial of Service (ReDoS) attack because the `multiplier` function in `parsers.js` contains a regular expression which isn’t optimized, processing user input. An attacker can craft and inject malicious input that will cause catastrophic backtracking in the regular expression engine by leveraging what the engine was designed to do - process all possibilities as it attempts to find a match. This extensive processing hangs the system within a matter of seconds.
Attack Mechanics:
Most regex engines behave in a very similar fashion by matching the first possible way to accept the current character and then proceed down the character chain. If the next match fails, the engine will look back and see if there was a different way to digest the previous character. If this process goes too far and the string doesn’t match in the end, or if many characters have multiple valid regex paths, the number of backward looking steps can become extremely large and result in catastrophic backtracking.
Remediation:
As discussed in the video, the most obvious way to prevent ReDoS attacks is to use best development practices and “hygiene”. In addition to crafting a more elegant regex syntax that meets your individual coding needs, unexpectedly long inputs, which may become a potential security hazard, must be accounted for.
Examples below for best practices:
Figure 1: The vulnerable regular expression being used for a string comparison
Figure 2: The optimized regular expression
In terms of CVE-2018-1109/Sonatype-2018-0081, in addition to utilizing best practices, it is recommended that you upgrade to non-vulnerable version of `braces`, i.e. 2.3.1 available at the npm repository.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2018-1109/Sonatype-2018-0081 within days of the discovery. Their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.
Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.
