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.)