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) How reproducible: always 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 Actual results: A sample error_log entry I got... [Tue Apr 03 20:48:19 2007] [error] [client 1.2.3.4] ModSecurity: Warning. Match of "rx (?:\\\\b(?:(?:i(?:nterplay|hdr|d3)|m(?:ovi|thd)|(?:ex|jf)if|f(?:lv|ws)|varg|cws)\\\\b|r(?:iff\\\\b|ar!B)|gif)|B(?:%pdf|\\\\.ra)\\\\b)" 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. Expected results: Cleaner logs, without the false positives. :) Additional info: Ideally, mod_security should be fixed upstream, to handle encoded content better. They are apparently aware of the problem, as suggested by this post... http://www.archivesat.com/mod-security_users/thread2630168.htm 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.