| Summary: | net-www/mod_security < 2.1.1 Rule bypass (CVE-2007-1359) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Pierre-Yves Rofes (RETIRED) <py> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | apache-bugs, chtekk, moonwalker |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.php-security.org/MOPB/BONUS-12-2007.html | ||
| Whiteboard: | B4 [glsa] p-y | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 151826 | ||
| Bug Blocks: | |||
|
Description
Pierre-Yves Rofes (RETIRED)
2007-03-07 15:13:21 UTC
*** 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 |