Vulnerability Details

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.


Mitigation

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.

References
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-v3-dos-vulnerability-in-four-transformations-cve-2023-38285/
https://github.com/SpiderLabs/ModSecurity/commit/ab5658f2d4cfa5126db256cf3f9dcb299982366d