colin353 / universe Goto Github PK

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.

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 took 413.95 seconds. In contrast, a 10MB random string took only 0.016 seconds. A 1MB attack string took 3.259 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,

Thanks for the tool!

When attempting to index the android source code:
https://source.android.com/setup/build/downloading

Code search exhausts my system memory after consuming ~20GB

Did you evaulate the possibility of using something like universal-ctags like other similar projects do?

Would love to use this with other languages! Great work!

If you made tools search available without requiring docker/bazel & friends,
I believe your work would be more reusable and more popular.

Please consider offering it as a cargo workspace with a number of cargo projects within managed by a Cargo.toml.
Please consider its different reusable subcomponents as different crates as managed by different Cargo.toml files.

This is in keeping with the usual rust build lifestyle where everything usually is built with cargo and its associated Cargo.toml.

Thank you for listening.