CVE-2020-13935 Apache Tomcat Websocket DoS 漏洞分析

文章首发于安全客，链接https://www.anquanke.com/post/id/222279

Apache Tomcat在9.0.37版本的更新中，修复了一个Websockt的拒绝服务漏洞

由于Websocket frame中的payload的长度没有正确验证，导致陷入了无限循环，造成拒绝服务。

Websocket 协议

RFC 6455中规定了Websocket frame的结构

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

前9位是一些标志位，接着7位为payload length，后面64位为扩展的payload length，payload len就是最后payload data的长度，对于扩展payload len，也做了详细的规定

Payload length:  7 bits, 7+16 bits, or 7+64 bits

     The length of the "Payload data", in bytes: if 0-125, that is the
     payload length.  If 126, the following 2 bytes interpreted as a
     16-bit unsigned integer are the payload length.  If 127, thec
     following 8 bytes interpreted as a 64-bit unsigned integer (the
     most significant bit MUST be 0) are the payload length.

当payload len为0-127之间时，payload len就是payload data的长度，当payload len为126时，只使用后面的2个字节作为payload data的长度，当payload len为127时，则说明后面的8个字节是payload data长度，这时64位的Extended Payload Len最高位必须为0，代表无符号整数

漏洞分析

补丁

先看Apache Tomcat官方的更新commit

在org/apache/tomcat/websocket/WsFrameBase.java中的processRemainingHeader函数中，当payloadLength为127时，获取新的payloadLength，增加了非负的判断。

代码分析

这里使用Apache Tomcat9.0.35+JDK1.8.0_271进行调试，首先在补丁代码处下断点

使用tomcat自带的examples中的Websocket的接口ws://localhost:8080/examples/websocket/echoProgrammatic，为了能让代码走到断点行，需要payload len为127，所以构造一个payload len为0b1111111，payload data为test的Websocket数据包发送

可以看到，inputBuffer就是我们发送的整个数据包，此时取出了其中的payload len为127，接着我们进入byteArrayToLong函数

这里start=2 len=8，也就是正好取出了Websocket数据包的16位之后的64位数据，也就是Extended Payload Length进行计算，每次取低8位进行byte到long的转换，由于long数据类型是64位有符号的Java原始数据类型，当计算到最高8位时，result将是一个负数，我们构造的数据包Extended Payload Length64位全为1，查看其结果

可以看到，最终结果是为负数，接着我们查看代码继续调试，寻找当payload len为负数时，会发生什么

当处理完payload len之后，当前state=State.DATA，由于已经计算出payload data的长度，此时需要用payload len来处理payload data，在processData函数增加断点，并跟踪进去

接着进入processDataText函数

进入transformation.getMoreData函数

主要功能就是把payload data通过payload len一字节一字节的取出来放到dst中，payloadWritten从0自增。当取完payload len的数据之后，不会在意之后是否还存在数据，就会返回END_OF_FRAME，如果payload len大于真实的payload data的长度，那么当发现inputBuffer没有数据了，就会返回UNDERFLOW，其他情况就会返回OVERFLOW，所以如果payload len为负数，那么也会返回OVERFLOW，接着返回到processDataText函数中，我们认真观察这段代码

正常情况下，会因END_OF_FRAME而直接不进入循环，当返回UNDERFLOW或者OVERFLOW两种状态时，会进入循环并进行messageBufferBinary也就是payload data的utf-8解码，当我们将payload len变为负数传入时，解码结果将返回UNDERFLOW，从而进入判断

由于payload len为负数，导致取payload data时返回的TransformationResult.OVERFLOW，从而utf-8解码的这个循环结束，再次调用tr = transformation.getMoreData(opCode, fin, rsv, messageBufferBinary);，进入读取payload data的循环，由于返回值依然是OVERFLOW，这样就进入了无限循环，导致CPU爆满，那么为什么OVERFLOW状态会导致这个循环的无限执行呢？

由于Websocket支持最大64位有符号数长度的payload data，而在取数据到messageBufferBinary时，只有8192的容量，所以当数据过长一次没有全部读取到Buffer时，会返回OVERFLOW用于后续循环再次读取