ModSecurity is an open-source Web Application Firewall (WAF) engine maintained by Trustwave. This blog post discusses an issue with four transformation actions that could enable a Denial of Service (DoS) attack by a malicious actor. The issue has been addressed with fixes in v3.0.10. ModSecurity v2 is not affected.
Included in ModSecurity functionality are dozens of transformation actions which support altering the representation of values so that further processing can be done on the modified values. This may be either more convenient to work with, or less prone to rule evasion.
The ModSecurity team was recently alerted to a possible DoS issue in four of these transformations in ModSecurity v3. Thanks to the reporter for the investigation and for responsibly disclosing the issue. The affected transformations are: removeWhitespace, removeNull, replaceNull, and removeCommentsChar.
The affected transformations were functionally correct. However, the implemented solutions would be inefficient if a malicious user were to submit a specially crafted HTTP request that triggered worst-case performance.
The most dramatic delays can typically be prevented through common configuration items such as SecRequestBodyNoFilesLimit with the default value of 131072 suggested in modsecurity.conf-recommended. However, even with this limit in place, a dozen or more executions of these transformations could result in multiple seconds of delay for a single HTTP transaction. If a large enough number of such malicious requests are running simultaneously, this could render the webserver unable to respond to legitimate requests in a timely manner.
For installations where immediate upgrade to the new version of the software is impractical, some mitigation possibilities are available.
The nature of the issue results in large values causing a much greater effect on resources than numerous smaller values. A separate ModSecurity rule could be included to limit the size of each value to be processed, but still allow legitimate content to be processed unimpeded. For example, if there are many rules with the affected transformations executing against the ARGS collection, a rule such as the following could be included before other phase 2 rules:
SecRule ARGS "@gt 16000" "id:1,phase:2,t:length,deny,status:403,msg:’ARG exceeds length limit'"
Optionally, combined with further reducing the configured value for SecRequestBodyNoFilesLimit, potential delays precipitated by worst-case input can be significantly reduced.