You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 12, 2024. It is now read-only.
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.
To evaluate the performance of this inefficient regular expression matching with varying input contents, the following commands can be executed within the PoC folder:
time ./poc AttackString10MB.txt
# real 72m38.173s# user 72m30.083s# sys 0m5.653stime ./poc RandomString10MB.txt
# real 0m0.029s# user 0m0.016s# sys 0m0.026stime ./poc AttackString1MB.txt
# real 0m54.028s# user 0m53.917s# sys 0m0.088stime ./poc RandomString1MB.txt
# real 0m0.011s# user 0m0.007s# sys 0m0.011s
The significant difference in processing time between random strings and malicious strings highlights the potential effectiveness of this regex for malicious exploitation. And as string length grows, the nonlinear increase in processing time reflects potentially greater risks.
Proposed Solution:
A possible mitigation strategy could include limiting the input length to prevent excessive processing times. If the corresponding function or feature is not in use, it is recommended to clean up risky third-party packages or code content to prevent malicious exploitation through methods such as code injection.
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,
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
pocassist/vendor/github.com/unknwon/com/html.go
Line 47 in 269099d
PoC Files and Comparisons:
PoC Files Here:
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:
The significant difference in processing time between random strings and malicious strings highlights the potential effectiveness of this regex for malicious exploitation. And as string length grows, the nonlinear increase in processing time reflects potentially greater risks.
Proposed Solution:
A possible mitigation strategy could include limiting the input length to prevent excessive processing times. If the corresponding function or feature is not in use, it is recommended to clean up risky third-party packages or code content to prevent malicious exploitation through methods such as code injection.
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,
The text was updated successfully, but these errors were encountered: