https://bugzilla.suse.com/show_bug.cgi?id=1213702 Bug ID: 1213702 Summary: VUL-0: CVE-2023-38285: modsecurity: DoS Vulnerability in Four Transformations Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Apache Assignee: apache-bugs@suse.de Reporter: gianluca.gabrielli@suse.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- 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-... https://github.com/SpiderLabs/ModSecurity/commit/ab5658f2d4cfa5126db256cf3f9... -- You are receiving this mail because: You are on the CC list for the bug.