从“Tomcat8.5 HTTP/2拒绝服务漏洞”来看混沌工程

内容分享7小时前发布

0 1 0

背景

[SECURITY] CVE-2020-11996 Apache Tomcat HTTP/2 Denial of Service

漏洞名称：Apache Tomcat HTTP/2 拒绝服务漏洞

漏洞编号：CVE-2020-11996

严重程度：重大

软件提供商：Apache 软件基金会

受影响的版本：

Apache Tomcat 10.0.0-M1 to 10.0.0-M5

Apache Tomcat 9.0.0.M1 to 9.0.35

Apache Tomcat 8.5.0 to 8.5.55

漏洞描述：

A specially crafted sequence of HTTP/2 requests could trigger high CPU usage for several seconds. If a sufficient number of such requests were made on concurrent HTTP/2 connections, the server could become unresponsive.

一个特别制作的HTTP/2请求序列，在短短数秒内能导致 CPU 满负载率，如果有足够数量多的此类请求连接(HTTP/2)并发放在服务器上，服务器可能会失去响应。

解决方案(升级)：

Apache Tomcat 10.0.0-M6 or later

Apache Tomcat 9.0.36 or later

Apache Tomcat 8.5.56 or later

另外从官方揭示的信息来看，Tomcat 8.5以下版本不受影响，由于Tomcat 8.5＋才开始有了对HTTP/2的支持。HTTP/2 拒绝服务漏洞还算好，由于Tomcat默认使用 HTTP/1.1协议，如果没有用HTTP/2就没问题，如果开启了就要注意升级了。

Credit归功于(贡献者)：

This issue was reported publicly via the Apache Tomcat Users mailing list without reference to the potential for DoS. The DoS risks were identified by the Apache Tomcat Security Team.

参考References：

http://tomcat.apache.org/security-10.html

http://tomcat.apache.org/security-9.html

http://tomcat.apache.org/security-8.html

原理

一个特别制作的HTTP/2请求序列，在短短数秒内能导致CPU满负载率。

乍一看漏洞描述，导致CPU满负荷，满足混沌工程注入的故障：CPU耗尽，但原理并没有说明，只有了解原理才能注入故障测试。

1) 官网找原理CVE-2020-11996(一般不说)

从http://tomcat.apache.org/security-10.html 查到Important: HTTP/2 DoS CVE-2020-11996

This was fixed with commit 9434a44d.

This issue was reported publicly via the Apache Tomcat Users mailing list on 21 May 2020 without reference to the potential for DoS. The DoS risks were identified by the Apache Tomcat Security Team the same day. The issue was made public on 25 June 2020.

找了一圈没看到原理说明的，估计安全都是根据修改提议，要么升级要么修改代码吧？

2) 官网看代码修改点(Improve performance of closing idle streams)

咱试着看看代码 Fix BZ 64467. Improve performance of closing idle streams · apache/tomcat@9434a44 · GitHub https://github.com/apache/tomcat/commit/9434a44d3449d620b1be70206819f8275b4a7509

从“Tomcat8.5 HTTP/2拒绝服务漏洞”来看混沌工程

以下是删除代码

private void closeIdleStreams(int newMaxActiveRemoteStreamId) throws Http2Exception {

for (int i = maxActiveRemoteStreamId + 2; i < newMaxActiveRemoteStreamId; i += 2) {

Stream stream = getStream(i, false);

if (stream != null) {

stream.closeIfIdle();

修改后代码

private void closeIdleStreams(int newMaxActiveRemoteStreamId) {

for (Entry<Integer,Stream> entry : streams.entrySet()) {

if (entry.getKey().intValue() > maxActiveRemoteStreamId &&

entry.getKey().intValue() < newMaxActiveRemoteStreamId) {

entry.getValue().closeIfIdle();

}

maxActiveRemoteStreamId = newMaxActiveRemoteStreamId;

}

看了上边代码，修改前针对消息流不为空则不关闭idle streams，修改后增加判断条件后才关闭idle streams。

3) 官网的BUG管理网站找问题的定位分析

ASF Bugzilla–Bug 64467 Http2 tomact server taking time in responding when 1st StreamId is a large integer value like 2147483641

https://bz.apache.org/bugzilla/show_bug.cgi?id=64467

We are running a Tomcat Http2 Server and a Jetty http2 client.

When we send the 1st request from jetty client to tomcat server with streamId as 2147483641, the 1st response from tomcat comes after almost 5 seconds.

After further debugging we got to know that the problem seems to be because of the below code in Http2UpgradeHandler class:

private void closeIdleStreams(int newMaxActiveRemoteStreamId) throws Http2Exception

{

for (int i = maxActiveRemoteStreamId + 2; i < newMaxActiveRemoteStreamId; i += 2)

{

Stream stream = getStream(i, false);

if (stream != null) {

stream.closeIfIdle();

}

maxActiveRemoteStreamId = newMaxActiveRemoteStreamId;

}

When we take 1st StreamId as 2147483641, the above loop takes around 4~5 seconds to execute and hence, the response is delayed.