Bugzilla Bug 169778

Stefan Esser has discovered a vulnerability in mod_security, which can be
exploited by malicious people to bypass certain security restrictions.

The problem is that it is possible to bypass rules by adding NULL bytes to POST
data with the application/x-www-form-urlencoded media type.

The vulnerability is confirmed in versions <= 2.1.0

*** Bug 170180 has been marked as a duplicate of this bug. ***

wrong naming

not fixed yet upstream

No upstream release yet, but they have a statement about the issue at:

http://www.modsecurity.org/blog/archives/2007/03/modsecurity_asc.html

should we consider a temporary-glsa with the mentionned workaround?

I know that's not in the policy, but i'm firstly concerned about our users'
information and protection.

Is someone in touch with upstream and could he tell us if a fix is to be
released?

If we have the resources I agree on a temp GLSA.

too late now i think. Any news from upstream? What about the other distros?

Upstream has released 2.1.1 which fixes this issue.

http://bugs.gentoo.org/show_bug.cgi?id=151826

has an ebuild for it, which works but maybe need some "adoption". Should be an
easy fix to close these 2 bugs.

mod_security-2.1.1 is in the tree thanks to phreak.
Best regards, CHTEKK.

thanks chtekk.
Arches, please test and mark stable mod-security-2.1.1.
Target keywords are: "x86 amd64 ppc sparc"

ppc stable

x86 stable

sparc stable.

This might be of interest from the mod_security maillist, in short a new core
ruleset has been released and as far as I understand it's not included in 2.1.1
but has been tested with that version. Maybe someone can make a patch or
something to bring them in? 

From List:

Dear ModSecurity users,

A new version of the core rules, 1.4, is now available at
http://www.modsecurity.org/download/index.html.
The rules have been tested with version 2.1.1, and might not work with an older
version.
Please note that this ruleset is newer than the rules bundled with version
2.1.1 of ModSecurity.
Here's a list of the changes made in this version:

----------
New Events
----------
- 970021 - WebLogic information disclosure
    Matching of "<title>JSP compile error</title>" in the response body, will
trigger this rule, with severity 4 (Warning)
- 950015,950910,950911 - HTTP Response Splitting
   HTTP Response Splitting is described in Amit Klein's excellent article:
   
http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
ModSecurity does not support compressed content at the moment. Thus, the
following rules have been added:
- 960013 - Content-Encoding in request not supported
    Any incoming compressed request will be denied
- 960051 - Content-Encoding in response not suppoted
    An outgoing compressed response will be logged to alert, but ONLY ONCE.

---------------------
False Positives Fixes
---------------------
The following FPs have been reported. They have been examined and found to be
commonly used in the web.
- Removed <.exe>,<.shtml> from restricted extensions
- Will not be looking for SQL Injection signatures <root@>,<coalesce> in the
Via request header
- Excluded Referer header from SQL injection, XSS and command injection rules
- Excluded X-OS-Prefs header from command injection rule
- Will be looking for command injection signatures in
  REQUEST_COOKIES|REQUEST_COOKIES_NAMES instead of REQUEST_HEADERS:Cookie.
- Allowing charset specification in the <application/x-www-form-urlencoded>
Content-Type
    i.e.: The following Content-Type will be allowed:
application/x-www-form-urlencoded; charset=ISO-8859-1
          (or any other valid charset)

----------------------
Additional rules logic
----------------------
- Corrected match of OPTIONS method in event 960015
    No transformation, and looking exactly for ^OPTIONS$, to dismiss it from
having an Accept header.
- Changed location for event 960014 (proxy access) to REQUEST_URI_RAW
    REQUEST_URI_RAW also contains the domain name, if provided by the client.
    In a normal case, a client will not provide the domain name in the URI
    The appearence of "http:/" in the URI, may imply an attempt for proxy
access.
- Moved all rules apart from method inspection from phase 1 to phase 2 -
    This will enable viewing content if such a rule triggers as well as setting
exceptions using Apache scope tags.
- Added match for double quote in addition to single quote for <or x=x>
signature (SQL Injection)
- Added 1=1 signature (SQL Injection)


Avi Aminov,
ModSecurity Core Rule Set Team

@Joakim: I noticed the updated core rules as well and they would be a nice
addition. But unless it has any relation to the problem on this bug I suggest
making a new bug for such a feature request.

amd64 stable

time to vote for GLSA. I tend to vote NO.

I'll vote yes - very common software used on public sites where information
disclosure could mean the compromise of the site (secured administrative web
pages, for example).

I vote yes, too.  This is used way too often to not give a GLSA.

2 yes votes, setting GLSA status.

GLSA 200705-17, thanks everybody