Regular Expression Denial of Service (REDoS).
Most default regular expression parsers (non-deterministic finite automata) have unbounded worst-case complexity. Regex matching may be quick when presented with a matching input string. However, certain non-matching input strings can make the regular expression matcher go into crazy loops and take ages to process. This can cause denial of service, as the CPU will be stuck trying to match the regex.
This tool is designed to:
- find regular expressions which are vulnerable to REDoS
- give an example malicious string which will cause catastrophic backtracking
Something something regexes are bad.
Not sure what to call this. This reflects the complexity of the regular expression matcher's backtracking procedure with respect to the length of the entered string.
With a starriness of 3, we have approximately cubic complexity. This means that if the vulnerable part of the string is doubled in length, the execution time should be 8 times longer (2^3).
For exponential REDoS with starred stars e.g. (a*)*$ a fudge factor is used and the starriness will be greater than 10.
For explotability, a cubic complexity or higher (starriness >= 3) is typically required unless truly giant strings are allowed as input.
Run regexploit and enter the regular expression abc*[a-z]+c+$ at the command line.
$ regexploit
abc*[a-z]+c+$
Pattern: abc*[a-z]+c+$
---
Starriness: 3 ⭐⭐⭐
Repeated character: [c]
Final character to cause backtracking: [^[a-z]]
Example: 'ab' + 'c' * 3456 + '0'
The part c*[a-z]+c+ contains three overlapping repeating groups. As showed in the line Repeated character: [c], a long string of c will match this section in many different ways. The starriness is 3 as there are 3 infinitely repeating groups. An example to cause REDoS is given: it consists of the required prefix ab, a long string of c and then a 0 to cause backtracking. Not all REDoSes require a particular character at the end, but in this case, a long string of c will match the regex successfully and won't backtrack. The line Final character to cause backtracking: [^[a-z]] shows that a non-matching character not in the range [a-z] is required at the end to prevent matching and cause REDoS.
As another example, install a module version vulnerable to REDoS such as pip install ua-parser==0.9.0.
To scan the installed python modules run regexploit-python-env.
Importing ua_parser.user_agent_parser
Vulnerable regex in /Users/b3n/Research/redosauto/.env/lib/python3.9/site-packages/ua_parser/user_agent_parser.py #183
Pattern: \bSmartWatch *\( *([^;]+) *; *([^;]+) *;
Context: self.user_agent_re = re.compile(self.pattern)
---
Starriness: 3 ⭐⭐⭐
Repeated character: [20]
Example: 'SmartWatch(' + ' ' * 3456
Starriness: 3 ⭐⭐⭐
Repeated character: [20]
Example: 'SmartWatch(0;' + ' ' * 3456
Vulnerable regex in /Users/b3n/Research/redosauto/.env/lib/python3.9/site-packages/ua_parser/user_agent_parser.py #183
Pattern: ; *([^;/]+) Build[/ ]Huawei(MT1-U06|[A-Z]+\d+[^\);]+)[^\);]*\)
Context: self.user_agent_re = re.compile(self.pattern)
---
Starriness: 3 ⭐⭐⭐
Repeated character: [[0-9]]
Example: ';0 Build/HuaweiA' + '0' * 3456
...
For each vulnerable regular expression it prints one or more malicious string to trigger REDoS. Setting your user agent to ;0 Build/HuaweiA000000000000000... and browsing a website using an old version of ua-parser may cause the server to take a long time to process your request, probably ending in status 502.
For now, clone and run
# Optionally make a virtualenv
python3 -m venv .env
source .env/bin/activate
# Now actually install
pip install -e .
(cd regexploit/bin/javascript; npm install --production)Enter regular expressions via stdin (one per line) into regexploit.
regexploitor via a file
cat myregexes.txt | regexploitNothing is printed when no REDoS is found.
Search for regexes in all the python modules currently installed in your path / env. This means you can pip install whatever modules you are interested in and they will be analysed. Cpython code is included.
regexploit-python-envN.B. this doesn't parse the python code to an AST and will only find regexes compiled automatically on module import. Modules are actually imported, so code in the modules will be executed.
Parses Python code (without executing it) via the AST to find regexes (with some false positives). The regexes are then analysed for REDoS.
regexploit-py my-project/stuff.py
regexploit-py "my-project/**/*.py" --globThis will use the bundled NodeJS package in regexploit/bin/javascript which parses your javascript as an AST with typescript-eslint and prints out all regexes.
Those regexes are fed into the python REDoS finder.
regexploit-js my-module/my-file.js another/file.js
regexploit-js "my-project/node_modules/**/*.js" --globN.B. there are differences between javascript and python regex parsing so there may be some errors. I'm not sure I want to write a JS regex AST!
TODO: not so straight forward to extract the regexes because of the way they are often built up from multiple strings.
TODO: not so straight forward to extract the regexes because of the way they are often built up from multiple strings. Can maybe grep for simple uses of preg_match and pipe into regexploit.
Unless you specifically use a non-deterministic finite automata, Go code is not vulnerable to this type of REDoS. It uses re2 which does not have catastrophic backtracking.