背景
[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
以下是删除代码
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管理网站找问题的定位分析
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.
这个触发条件大致知道了，但使用什么工具触发的呢？怎么触发的呢？有木有开源工具啊？开源工具能不能拿过来借鉴下，加入混沌工程中来测试啊？
参考
