A flaw was found in the default error response for status code 400. This could be used by an attacker to expose "httpOnly" cookies, when no custom ErrorDocument was specified. This affects all versions of Apache from 2.2.0 up to and including 2.2.21. It will be fixed upstream in 2.2.22 (via r1235454 [1]). [1] http://svn.apache.org/viewvc?view=revision&revision=1235454
Created httpd tracking bugs for this issue Affects: fedora-all [bug 785070]
====================================================== Name: CVE-2012-0053 protocol.c in the Apache HTTP Server 2.2.x through 2.2.21 does not properly restrict header information during construction of Bad Request (aka 400) error documents, which allows remote attackers to obtain the values of HTTPOnly cookies via vectors involving a (1) long or (2) malformed header in conjunction with crafted web script.
Upstream fix (linked in comment #0) changes the amount of information sent back to an HTTP client when httpd detects one of the following problems: 1) HTTP request header line is longer than configured LimitRequestFieldSize limit. In this case, httpd adds the line (actually, a prefix of it read before reaching the limit) to its default 400 error page. 2) HTTP request header line is continuation of the previous line and both lines combined together exceed configured LimitRequestFieldSize limit. In this case, httpd adds previous line to its default 400 error page. Note: previous line here may refer to a concatenation of more than one line, if previous lines were continuations too. 3) HTTP request header line does not contain : , which is a separator between the header name and its value. Case 1) is the one that can be used by malicious javascript to gain access to httpOnly cookies. A script can set additional cookies to make Cookie: request header line length exceed LimitRequestFieldSize and read values of a httpOnly protected cookies from the httpd's error page. This may allow a script injected via some XSS flaw to gain access to cookies it can not access directly. Upstream fix ensures that error page only contains header name, or 80 character prefix of the header name, if the name exceeds that limit.
Write up of the issue for the original reporter: http://fd.the-wildcat.de/apache_e36a9cf46c.php It confirms the analysis above (comment #4).
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2012:0128 https://rhn.redhat.com/errata/RHSA-2012-0128.html
Is httpd-2.2.3-53 impacted by the issue httpd-2.2.3-53 ? (RHEL 5)
(In reply to comment #10) > Is httpd-2.2.3-53 impacted by the issue httpd-2.2.3-53 ? (RHEL 5) This issue affects the version of the httpd package, as shipped with Red Hat Enterprise Linux 5.
(In reply to comment #11) Can you clarify. Does this mean the issue has been resolved as of httpd-2.2.3-53 or that the issue has not been addressed. CVE Mitre currently is point at this bug track thread for updates and resolutions and has not marked it definitively resolved. Thanks
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2012:0323 https://rhn.redhat.com/errata/RHSA-2012-0323.html
(In reply to comment #12) > (In reply to comment #11) > > Can you clarify. > > Does this mean the issue has been resolved as of httpd-2.2.3-53 or that the > issue has not been addressed. John, it has been resolved now via RHSA-2012:0323. Previously it was vulnerable.
Hi, Any information on that status of the EWS fixes for this CVE?
(In reply to comment #15) > Hi, > > Any information on that status of the EWS fixes for this CVE? Hi Blair, We are working towards addressing of this issue in various versions of JBoss Enterprise Web Server too. But unfortunately as of right now we are unable to provide exact release date, when the updates can be expected (as the final date is subject of change depending on couple of internal conditions). Hope the above being sufficient and helpful. Apologize, but can't provide more exact information. Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
Statement: This issue affects httpd packages as shipped with Red Hat Enterprise Linux 3 and 4, which are now in the Extended Life Phase of their life cycle. Therefore this issue is not planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/
Note that this issue does affect Apache 2.0 despite the Mitre CVE description. Verification: https://svn.apache.org/viewvc/httpd/httpd/branches/2.0.x/STATUS?view=diff&r1=1237164&r2=1237165&pathrev=1237165
Are we making any kind of progress on this for EWS 1.0.2 (tomcat 6.0.32)?
Sorry, this isn't a tomcat issue, I meant to inquire about EWS 1.0.2's Apache (2.2.17)...
This issue has been addressed in following products: JBoss Enterprise Web Server 1.0.2 Via RHSA-2012:0543 https://rhn.redhat.com/errata/RHSA-2012-0543.html
This issue has been addressed in following products: JBEWS 1.0 for RHEL 5 JBEWS 1.0 for RHEL 6 Via RHSA-2012:0542 https://rhn.redhat.com/errata/RHSA-2012-0542.html
Mitigation instructions: As noted in the original reporter's advisory (see comment #5), this issue can be mitigated by using a custom ErrorDocument setting, such as: ErrorDocument 400 "Bad Request" http://httpd.apache.org/docs/2.2/mod/core.html#errordocument It should be noted that ErrorDocument setting using path or external URL does not mitigate this issue. It should also be noted that this is not an issue by itself. This can only be exploited via some other cross-site scripting (XSS) flaw found in a web application running on the server and may allow injected JavaScript to gain access to HttpOnly cookies, if the application uses this protection for its cookies.