Bug 785069 (CVE-2012-0053)
Summary: | CVE-2012-0053 httpd: cookie exposure due to error responses | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | bmorriso, csutherl, davids, denis.kosierk, jawilson, jkaluza, jlieskov, john.willis, jorton, mjc, pahan, prc, rhui |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | httpd 2.2.22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-05-07 19:37:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 746695, 746696, 746697, 785070, 787596, 787597, 787598, 787599 | ||
Bug Blocks: | 785071 |
Description
Vincent Danen
2012-01-27 06:27:17 UTC
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. |