CVE-2020-11100 haproxy：错误格式的 HTTP/2 请求可能导致越界写入问题

摘要

红帽已了解到，HAProxy 在处理某些 HTTP/2 请求数据包的方式中存在问题。  攻击者可以通过发送精心设计的 HTTP/2 请求数据包来造成内存损坏的问题，从而导致系统崩溃或可以使用运行 HAProxy 的用户的权限远程执行任意代码。 

这个问题已被记录为 CVE-2020-11100，严重性级别被定为 Critical（严重）。

受影响的产品

受 CVE-2020-11100 影响的红帽产品

受影响产品的更新

技术详情和背景信息

HAProxy 是一个 TCP/HTTP 反向代理，它被设计为用于高可用性环境。 HAProxy 通常被部署在应用程序服务器群集的前面，并将传入的请求分配到集群中的一台服务器，从而提高性能和高可用性。 当与网站一起部署时，HAProxy 可以选择使用 HTTP/2 协议来更有效地利用网络资源。

HAProxy 处理 HTTP/2 请求数据包的方式中存在此缺陷。 

Red Hat Enterprise Linux 6 和 7 提供的 HAProxy 软件包并没有包括对 HTTP/2 的支持，所以不受这个安全漏洞的影响。

从 OpenShift Container Platform 4 到 4.3 的版本中都包括存在这个安全漏洞的代码。但是，利用这个安全漏洞需要在 OpenShift Ingress Operator 中设置 ROUTER_USE_HTTP2，目前这是不可能的。因此，此漏洞对 4.4 版之前的 OCP 4.x 系统的影响较低。

OpenShift Container Platform 3.11 添加了一个 ose-haproxy-router 配置选项，使用它可以启用 HTTP/2 支持。但是，它在该版本上没有被默认启用。

缓解方案

针对受影响产品的安全勘误将尽快发布；请参阅上表中的信息。如果用户需要在程序修复发布前寻求解决方案，或希望寻求替代解决方案，请参考以下的缓解方案。

在 Red Hat Enterprise Linux 8上，HAProxy 受 SELinux 的限制，这可以缓解远程任意代码执行的问题。  

这个问题还可以通过不启用对 HTTP/2 协议的支持加以缓解。红帽产品所提供的默认 HAProxy 配置是禁用 HTTP/2，但客户的实际环境中可能会更改这些默认设置。

您可以通过在 HAProxy 配置文件中搜索包含“ h2” 的行，检查其中的内容来决定是否已启用了 HTTP/2。 它们通常与以下类似：
    bind :443 ssl crt pub.pem alpn h2,http/1.1

要在 OpenShift Container Platform 3.11 中缓解此漏洞，使用默认的配置禁用 HTTP/2，如果已启用它，则将其禁用。

您还可以使用 curl 命令行工具验证是否在特定服务器上启用了 HTTP/2 支持，如下所示。 请注意，在这两个例子中，客户端都使用了 HTTP/2，但只有第一个例子中的服务器接受 HTTP/2。 在以下命令中使用您自己的主机名。

$ curl -v --http2 https://h2-enabled.example.com/ 2>&1 >/dev/null | grep ALPN 
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server accepted to use h2

$ curl -v --http2 https://h2-not-enabled.example.com/ 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

**请注意，如果后端服务器提供对 HTTP/2 的响应，且HAProxy 使用 passthrough 模式，则此测试将显示 HTTP/2 正在使用。 如果测试结果显示没有使用 HTTP/2，则说明不支持 HTTP/2。 如果测试结果显示在使用 HTTP/2，则需要对配置做进一步的检查，以决定在什么地方接受了 HTTP/2 的响应。 如果测试结果显示在使用 HTTP/2，而您认为您没有使用HTTP/2，请检查路由配置是否使用了 passthrough 模式。

“Cluster Console”（在 openshift-console 项目中）是测试 OpenShift Container Platform 3.11 的最佳URL，因为它不使用 passthrough 路由。请注意，这个路由与 “Application Console”（在 openshift-web-console 项目中）不同，后者没有通过路由器 Pod 代理。

$ curl -v --http2 https://console.apps.example.com 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

OpenShift Container Platform 3.11 中的 API 服务器是一个使用 passthrough 路由的例子。  虽然它位于 haproxy 之后，但 passthrough 意味着连接会在启用了 HTTP/2 的 golang 二进制文件的 Pod 内终止。  在这种情况下检测到的是位于 apiserver 容器内的服务器启用了 HTTP/2，而不是路由器 pod 中的可能有漏洞的 haproxy 启用了它。

$ curl -v --http2 https://apiserver-kube-service-catalog.apps.example.com 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

致谢

红帽感谢 HAProxy 项目团队报告了此问题。上游社区确认 Google Project Zero 的 Felix Wilhelm 是此安全问题的最初报告者。

参考信息

Google Project Zero 

HAProxy 团队博客