A flaw was found in the way haproxy processed certain HTTP/2 request packets. An attacker could send crafted HTTP/2 request packets which cause memory corruption, leading to a crash or potential remote arbitrary code execution with the permissions of the user running haproxy.
Created attachment 1675022 [details] Description + proposed patch
This was assigned CVE-2020-11100. Any change the product bugs are coming soon?
Statement: HAProxy packages shipped with Red Hat Enterprise Linux 6 and 7 do not contain support for HTTP/2; therefore, they are not affected by this flaw. OpenShift Container Platform versions through 4.3 contain the vulnerable code; exploitation requires setting ROUTER_USE_HTTP2 in the OpenShift Ingress Operator, which is not currently possible. The impact of this vulnerability is therefore reduced in OCP 4.x, prior to version 4.4, to low. OpenShift Container Platform 3.11 added a configuration option to ose-haproxy-router that made enabling HTTP/2 support easy. However, it is not enabled by default on that version.
Acknowledgments: Name: the HAProxy project Upstream: Felix Wilhelm (Google Project Zero)
Created haproxy tracking bugs for this issue: Affects: fedora-all [bug 1820185]
Upstream commit at: https://git.haproxy.org/?p=haproxy.git;a=commit;h=5dfc5d5cd0d2128d77253ead3acf03a421ab5b88
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions Via RHSA-2020:1289 https://access.redhat.com/errata/RHSA-2020:1289
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS Via RHSA-2020:1290 https://access.redhat.com/errata/RHSA-2020:1290
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1288 https://access.redhat.com/errata/RHSA-2020:1288
Mitigation: This issue can be mitigated by not enabling support for HTTP/2 protocol. Upstream suggests that HTTP/2 can be enabled per front-end server by using the following documentation: https://www.haproxy.com/documentation/hapee/1-8r1/traffic-management/enable-http2-protocol/. You can check if http2 is enabled by searching your haproxy configuration files for a line containing 'h2'. To mitigate this vulnerability in OpenShift Container Platform 3.11, keep HTTP/2 disabled as it is by default. You can verify if HTTP/2 support is enabled or not by following the instructions in following article: https://access.redhat.com/security/vulnerabilities/haproxy On Red Hat Enterprise Linux 8, haproxy is confined by SELinux, which should mitigate remote arbitrary code execution.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-11100
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 3.11 Via RHSA-2020:1287 https://access.redhat.com/errata/RHSA-2020:1287
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.4 Via RHSA-2020:1936 https://access.redhat.com/errata/RHSA-2020:1936
External References: https://www.mail-archive.com/haproxy@formilux.org/msg36876.html https://www.haproxy.com/blog/haproxy-1-8-http-2-hpack-decoder-vulnerability-fixed/ https://bugs.chromium.org/p/project-zero/issues/detail?id=2023