Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential ReDoS Vulnerability or Inefficient Regular Expression in Project: Need for Assessment and Mitigation #5

Open
SuperMaxine opened this issue Dec 27, 2023 · 0 comments

Comments

@SuperMaxine
Copy link

Hello,

I am writing to report a potential Regular Expression Denial of Service (ReDoS) vulnerability or Inefficient Regular Expression in the project. This issue arises when specially crafted input strings are used in the context of distributed, high-volume requests, potentially leading to a denial-of-service attack.

Location of Issue:

The vulnerability is related to a regular expression used in the following validation file, which may result in significantly prolonged execution times under certain conditions.

static ref RE_CONTROL_BLOCK: Regex = Regex::new(r"##.*?##|\{#.*?#\}").unwrap();

PoC Files and Comparisons:

PoC.zip

To evaluate the performance of this inefficient regular expression matching with varying input contents, the following commands can be executed within the PoC folder:

cargo build --release # Build the PoC executable file
time ./target/release/redos AttackString10MB.txt
time ./target/release/redos RandomString10MB.txt
time ./target/release/redos AttackString1MB.txt
time ./target/release/redos RandomString1MB.txt

These commands measure the time taken for the regular expression to match different types of strings. The results on my machine are as follows: For a 10MB attack string, the processing time exceeded 10 minutes. In contrast, a 10MB random string took only 0.016 seconds. A 1MB attack string took 12.336 seconds. By comparison, a 1MB random string took merely 0.005 seconds.

Proposed Solution:

A possible mitigation strategy could include limiting the input length to prevent excessive processing times.

Additional Considerations:

Historically, it was believed that using regex engines with non-backtracking implementations (such as those in Rust or Go) would not lead to ReDoS vulnerabilities. However, recent studies have shown that this is not always the case. I recommend an assessment of how this issue might impact this project.

Thank you for your attention to this matter. Your evaluation and response to this potential security concern would be greatly appreciated.

Best regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant