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. ***
not fixed yet upstream
No upstream release yet, but they have a statement about the issue at:
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.
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.
Arches, please test and mark stable mod-security-2.1.1.
Target keywords are: "x86 amd64 ppc sparc"
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?
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:
- 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:
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)
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.
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