|Summary:||CVE-2016-8743 httpd: Apache HTTP Request Parsing Whitespace Defects|
|Product:||[Other] Security Response||Reporter:||Adam Mariš <amaris>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||apmukher, bbaranow, bkundal, bmaxwell, bphinz, cdewolf, csutherl, dandread, dankobrin, darran.lofthouse, dosoudil, fnasser, gzaronik, hhorak, huwang, jason.greene, jawilson, jboss-set, jclere, jkaluza, jorton, lgao, luhliari, mbabacek, mdshaikh, mfrodl, mmilgram, mturk, myarboro, pahan, pgier, pragshar, psakar, pslavice, psotirop, rmeggins, rnetuka, rsvoboda, sardella, tgfurnish, tmishler, tschaibl, twalsh, vtunka, weli, xdmoon, yozone|
|Fixed In Version:||httpd 2.4.25||Doc Type:||If docs needed, set a value|
It was discovered that the HTTP parser in httpd incorrectly allowed certain characters not permitted by the HTTP protocol specification to appear unencoded in HTTP request headers. If httpd was used in conjunction with a proxy or backend server that interpreted those characters differently, a remote attacker could possibly use this flaw to inject data into HTTP responses, resulting in proxy cache poisoning.
|Last Closed:||2017-07-11 20:32:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1406823, 1412974, 1412975, 1412976, 1425463, 1427675, 1448328, 1448329|
|Bug Blocks:||1406828, 1457678|
Description Adam Mariš 2016-12-21 15:01:58 UTC
Apache HTTP Server, prior to release 2.4.25, accepted a broad pattern of unusual whitespace patterns from the user-agent, including bare CR, FF, VTAB in parsing the request line and request header lines, as well as HTAB in parsing the request line. Any bare CR present in request lines was treated as whitespace and remained in the request field member "the_request", while a bare CR in the request header field name would be honored as whitespace, and a bare CR in the request header field value was retained the input headers array. Implied additional whitespace was accepted in the request line and prior to the ':' delimiter of any request header lines. These defects represent a security concern when httpd is participating in any chain of proxies or interacting with back-end application servers, either through mod_proxy or using conventional CGI mechanisms. In each case where one agent accepts such CTL characters and does not treat them as whitespace, there is the possiblity in a proxy chain of generating two responses from a server behind the uncautious proxy agent. In a sequence of two requests, this results in request A to the first proxy being interpreted as requests A + A' by the backend server, and if requests A and B were submitted to the first proxy in a keepalive connection, the proxy may interpret response A' as the response to request B, polluting the cache or potentially serving the A' content to a different downstream user-agent. Affects versions since 2.2.0 up to 2.4.23 External Reference: https://httpd.apache.org/security/vulnerabilities_24.html#2.4.25
Comment 1 Adam Mariš 2016-12-21 15:04:26 UTC
Created httpd tracking bugs for this issue: Affects: fedora-all [bug 1406823]
Comment 6 Brian Hinz 2017-01-31 13:26:23 UTC
I realize that backporting the upstream fix is non-trivial, but is there any kind of status update that you can provide regarding a potential errata release date? The status is still marked as "NEW", which implies that it's not even being worked on... Thanks in advance.
Comment 7 Luboš Uhliarik ✈ 2017-01-31 13:40:58 UTC
Dear Brian, please check bugs for RHEL-7, RHEL-7 Z-stream and RHEL-6. They are all in modified state. I've finished backporting and QE should now take care of it. This is just tracking bug. Thanks for understanding.
Comment 11 Dan 2017-03-01 16:51:36 UTC
I am unable to access any of the related bugs for this to see what is going on. Can someone working this issue post a status update here? Thanks
Comment 12 Michal Karm Babacek 2017-03-01 17:43:58 UTC
Hi Dan, what exactly would you like to learn? If you seek support, use the Customer Portal, please. If you are coming from the community, you could find all pertinent information here  and a small clarification here . Cheers -K-  https://httpd.apache.org/security/vulnerabilities_24.html  https://bz.apache.org/bugzilla/show_bug.cgi?id=60783
Comment 13 Dan 2017-03-01 21:55:08 UTC
(In reply to Michal Karm Babacek from comment #12) > Hi Dan, what exactly would you like to learn? > > If you seek support, use the Customer Portal, please. > > If you are coming from the community, you could find all pertinent > information here  > and a small clarification here . > > Cheers > -K- > >  https://httpd.apache.org/security/vulnerabilities_24.html >  https://bz.apache.org/bugzilla/show_bug.cgi?id=60783 I would like to learn if and when RedHat will release an updated httpd package to address this CVE for RHEL6 and 7.
Comment 14 Trever 2017-03-02 16:53:30 UTC
There's a comment from a month ago that says the backporting is already completed. How long should it take to get from there to a package released to customers? See comment 7: Luboš Uhliarik 2017-01-31 08:40:58 EST: Dear Brian, please check bugs for RHEL-7, RHEL-7 Z-stream and RHEL-6. They are all in modified state. I've finished backporting and QE should now take care of it. This is just tracking bug. This is a high-scoring security problem on everyone's PCI scanners -- it's scoring 4.4, so your customers have to address it within 30 days of detection, and neither of your current RHEL platforms have a fix yet. This is a pretty bad situation to leave customers in.
Comment 15 Dan 2017-03-02 18:07:19 UTC
I had found several weeks ago in one of the related bugs (that I can no longer access) that the patched package Lubos mentioned had caused issues with yum and/or satellite server, so there is probably still work going on to fix this, but no status update here is bad.
Comment 16 Adam Mariš 2017-03-03 09:49:46 UTC
Hello Dan, Trever, Tracking bugs for the specific products, i.e. RHEL-6 and RHEL-7 in this case, are almost always kept private. As you've already found out, there were some problems with the patch which caused the delay, but we're working on fixing this issue. If you have some questions, please email email@example.com. Thank you!
Comment 17 tmishler 2017-04-05 20:00:43 UTC
Hello, Adam: This bug has many customer cases connected. Is there an ETA we can share with our clients? Thank you!
Comment 18 errata-xmlrpc 2017-04-12 12:32:14 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:0906 https://access.redhat.com/errata/RHSA-2017:0906
Comment 19 Trever 2017-04-12 21:06:19 UTC
(In reply to errata-xmlrpc from comment #18) > This issue has been addressed in the following products: > > Red Hat Enterprise Linux 7 > > Via RHSA-2017:0906 https://access.redhat.com/errata/RHSA-2017:0906 Is it still going to be addressed in RHEL 6?
Comment 20 errata-xmlrpc 2017-04-26 10:23:25 UTC
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Via RHSA-2017:1161 https://access.redhat.com/errata/RHSA-2017:1161
Comment 21 Trever 2017-04-26 18:50:18 UTC
(In reply to errata-xmlrpc from comment #20) > This issue has been addressed in the following products: > > Red Hat Software Collections for Red Hat Enterprise Linux 6 > Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS > Red Hat Software Collections for Red Hat Enterprise Linux 7 > Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS > > Via RHSA-2017:1161 https://access.redhat.com/errata/RHSA-2017:1161 Does that mean that it won't also be addressed in the main (non-SCL)channel for RHEL6?
Comment 22 Tomas Hoger 2017-04-27 09:17:00 UTC
This httpd fix uncovered a bug in the yum-rhn-plugin, which prevents yum from being able to install updates from Red Hat Satellite 5, Red Hat Satellite Proxy 5, or Red Hat Network if httpd fix is applied on the server side. The following knowledge base article provides further information about this problem and provides instructions on how to avoid it. https://access.redhat.com/articles/3013361
Comment 25 errata-xmlrpc 2017-06-07 17:45:47 UTC
This issue has been addressed in the following products: Red Hat JBoss Core Services Via RHSA-2017:1415 https://access.redhat.com/errata/RHSA-2017:1415
Comment 26 errata-xmlrpc 2017-06-07 17:57:31 UTC
This issue has been addressed in the following products: JBoss Core Services on RHEL 6 Via RHSA-2017:1414 https://access.redhat.com/errata/RHSA-2017:1414
Comment 27 errata-xmlrpc 2017-06-07 18:00:15 UTC
This issue has been addressed in the following products: JBoss Core Services on RHEL 7 Via RHSA-2017:1413 https://access.redhat.com/errata/RHSA-2017:1413