Red Hat Bugzilla – Bug 235304
false positives from modsecurity_crs_50_outbound.conf for responses with encoded content
Last modified: 2007-11-30 17:12:01 EST
Description of problem:
Rules in the modesecurity_crs_50_outbound.conf file report false positives
(fortunately just as warnings, and not as severe errors) for valid responses to
legitimate requests, if those responses have encoded content that happens to
match one of the (very brief) regular expressions.
Version-Release number of selected component (if applicable):
2.1.0-3.fc5 (as well as .fc6)
Steps to Reproduce:
1. Install mod_security, run "service httpd restart"
2. Access pages that will have encoded content (e.g. from mediawiki)
3. View error_log, modsec_audit.log, and modsec_debug.log
A sample error_log entry I got...
[Tue Apr 03 20:48:19 2007] [error] [client 18.104.22.168] ModSecurity: Warning. Match
against "RESPONSE_BODY" required. [id "970903"] [msg "ASP/JSP source code
leakage"] [severity "WARNING"] [hostname "www.example.com"] [uri
"/mediawiki/index.php"] [unique_id "pg-Qn4KzHDUAAB-pXHcAAAAE"]
Since some of the rules (id 970903 and 970902) have very short regular
expressions ("\<\%" and "<\?(?!xml)", resp.) requiring only a couple characters
to match, compressed binary data can easily trigger them. The chained rules
that follow are negative rules, so we typically don't get a match on those,
resulting in a false positive.
Cleaner logs, without the false positives. :)
Ideally, mod_security should be fixed upstream, to handle encoded content
better. They are apparently aware of the problem, as suggested by this post...
In the meantime, the rules can be "toughened up" a bit to avoid the false
positives. (See attached patch.)
Created attachment 151718 [details]
patch to modsecurity_crs_50_outbound.conf
Yeah, this should really be an upstream fix and reported there (I take the stock
Core Rules without adjustments or patches in my regular builds) however the
patch looks simple enough - I'll give them a local run and if there's no
negative impact I'll run up a new build to fix this one.
Can you try this with an updated Fedora + mod_security? The core rules have been
updated since this version and may no longer need patching.
Plus, FC5 is EOL - but you probably knew that anyway. I'm about to push 2.1.3
out the door in the next day or so for most branches.