0x00 漏洞背景
2019年08月13日晚,Netflix 安全团队联合Google，CERT / CC向互联网披露了 HTTP/2 协议在被各个中间件服务实现过程中出现的 DDoS(分布式-拒绝服务攻击)漏洞的问题。
0x01 漏洞详情
HTTP/2(在RFCs 7540和7541中定义)代表了与HTTP/1.1的区别以及产生的重大变化。有几种新的功能，包括报头压缩和来自多个流的数据的多路复用，这使得它对用户群体具有吸引力。为了支持这些新功能，HTTP/2已经发展到包含第3层传输协议的一些复杂性:
- 数据现在以二进制帧的形式传输；
- 每个连接和每个流窗口都定义了可以发送多少数据；
- 有几个类似ICMP的控制消息(例如ping、reset和设置帧)在HTTP/2连接层运行；
- 这是一个相当健壮的流优先级概念。
虽然这种增加的复杂性带来了一些激动人心的新特性，但也带来了实现问题。当实现在互联网上运行并暴露给恶意用户时，实现者可能会想:
- 我应该限制任何控制消息吗？
- 如何以计算高效性的方式实现优先级排队方案？
- 如何以计算高效性的方式实现流量控制算法？
- 攻击者如何在HTTP/2层操纵流量控制算法，从而导致意想不到的结果？(他们能同时操纵在超文本传输协议层和应用层的流量控制算法来产生意想不到的结果吗？)
RFC 7540的安全考虑部分(见第10.5节)以一般方式解决了其中的一些问题。然而，与预期的“正常”行为不同。对于标准中的确切描述来说，在被实现的时候只是满足了接近预期而已。例如用于检测和减轻“异常”行为的算法和机制明显更加模糊，这将是实现者所担负的实践与练习。从对各种中间件软件包的实现回顾来看，这其中有了各种各样的实现，有各种各样的好想法，但这其中也缺点的产生，这就造成了此次的漏洞。
为何影响
这些攻击大多在HTTP/2传输层进行。如下图所示，该层位于TLS传输之上，但在请求概念之下。事实上，许多攻击都涉及0或1个请求。
从早期的超文本传输协议开始，中间件服务就以请求为导向:日志以请求为分割(而不是连接)；速率限制发生在请求级别；并且流量控制也由请求触发。
相比之下，没有多少工具可以根据客户端在HTTP/2连接层的行为来执行记录、速率限制和修正。因此，中间件服务可能会发现更难发现和阻止恶意的HTTP/2连接，并且可能需要添加额外的工具来处理这些情况。
这些攻击媒介允许远程攻击者消耗过多的系统资源。有些攻击足够高效，单个终端系统可能会对多台服务器造成严重破坏（服务器停机/核心进程崩溃/卡死）。其他攻击效率较低的情况则产生了一些更棘手的问题，他们只会使服务器的运行变得缓慢，可能会是间歇性的，这样的攻击会更难以检测和阻止。
攻击状况
我们发现的许多攻击向量(今天已经修复)都是一个关键点的变体:一个恶意客户端要求服务器做一些产生响应的行为，但是客户端拒绝读取响应。这将考验服务器的队列管理代码。根据服务器处理队列的方式，客户端可以在处理请求时强制它消耗多余的内存和CPU。
- CVE-2019-9511 “Data Dribble”:攻击者通过多个流从指定资源请求大量数据。它们操纵窗口大小和流优先级，迫使服务器将数据按1字节块排队。根据这些数据排队的效率，这可能会消耗过多的CPU、内存或两者兼而有之，从而可能导致拒绝服务。
- CVE-2019-9512 “Ping Flood”:攻击者向一个HTTP/2对等方发送连续的Ping，导致对等方建立一个内部响应队列。根据这些数据排队的效率，这可能会消耗过多的CPU、内存或两者兼有，从而可能导致拒绝服务。
- CVE-2019-9513 “Resource Loop”:攻击者创建多个请求流，并以对优先级树造成实质性变动的方式不断打乱流的优先级。这会消耗过多的CPU，可能导致拒绝服务。
- CVE-2019-9514 “Reset Flood”:攻击者打开多个流，并在每个流上发送无效请求，该请求应该从对等方请求RST_STREAM帧流。根据对等端对RST流帧的排队方式，这可能会消耗过多的CPU、内存或两者兼有，从而可能导致拒绝服务。
- CVE-2019-9515 “Settings Flood”:攻击者向对等方发送一系列设置帧。因为RFC要求对等方在每个设置帧中回复一个确认，所以空的设置帧在行为上几乎等同于ping。根据这些数据排队的效率，这可能会消耗过多的CPU、内存或两者兼有，从而可能导致拒绝服务。
- CVE-2019-9516 “0-Length Headers Leak”:攻击者发送一个具有0长度报头名称和0长度报头值的报头流，可选地霍夫曼编码为1字节或更长的报头。一些实现为这些头分配内存，并保持分配活动，直到会话结束。这会消耗过多的内存，可能导致拒绝服务。
- CVE-2019-9517 “Internal Data Buffering”:攻击者打开HTTP/2窗口，这样对等方就可以不受限制地发送；但是，它们会关闭TCP窗口，因此对等端实际上无法在线路上写入(许多)字节。然后，攻击者发送一系列对大型响应对象的请求。根据服务器对响应的排队方式，这可能会消耗过多的内存和CPU，从而可能导致拒绝服务。
- CVE-2019-9518 “Empty Frames Flood”:攻击者发送带有空有效载荷且没有流结束标志的帧流。这些帧可以是DATA, HEADERS, CONTINUATION 或 PUSH_PROMISE。节点上对每一帧的处理时间和带宽不成正比。这会消耗过多的CPU，可能导致拒绝服务。(谷歌的Piotr Sikora发现)
0x02 修复建议
Nginx 已确认受到影响并已针对此次漏洞情况发布更新
其他的中间件服务尚无明确的响应和修复
360CERT 建议广大用户及时更新 http服务中间件的版本以免受到此次漏洞影响。
0x03 时间线
2019-08-13 360CERT监测到Netflix发布通告
2019-08-14 360CERT发布预警