For July's Sonatype Intelligence Insight, we take a deep dive into a Denial of Service (DoS) vulnerability impacting the popular Apache Tomcat Websocket component.
The vulnerability originates due to improper validation of the incoming payload length. Should an attacker be able to submit a payload of an invalid length, they can trigger an "infinite loop" within the component. Multiple such requests made by the attacker during a course of a session would cause a Denial of Service condition.
The original report made to the Apache team merely pointed out this "bug" without regard for its abuse and potential to cause DoS. "This issue was reported publicly via the Apache Tomcat Users mailing list without reference to the potential for DoS," reads the advisory released by the project, further stating, "The DoS risks were identified by the Apache Tomcat Security Team."
Name/vulnerability identifier: CVE-2020-13935
Type of vulnerability: Denial of Service (DoS)
Severity
CVSS 3.1 Score: 5.9 / Medium
CVSS 3.1 Metrics: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Components affected:
maven:
org.apache.tomcat:tomcat-websocket
[10.0.0-M1 , 10.0.0-M7)
[9.0.0.M1 , 9.0.37)
[8.5.0, 8.5.57)
org.apache.tomcat:tomcat7-websocket
( , 7.0.105)
For detecting other components containing the vulnerable Tomcat WebSocket classes and for detailed, most up to date vulnerability information, a free Sonatype Vulnerability scan is recommended.
The original report of the bug made by the user "niuhailiang" can be traced back to June 28, 2020. In the report, the user stated, "If all bits (7+64) of the payload length in one websocket frame are 1, the length will be resolved to a negative value which will cause an endless loop. The result is CPU usage is high and will not drop!"
In a screenshot posted along with the bug report, the user demonstrated how it was possible to achieve a final "payloadLength" calculation of "-2" during a debug exercise, thereby triggering the infinite loop.
Image: Previously, the arithmetic operation could have returned a negative value (“-2”, in this example) for `payloadLength` which was not being checked
(Source: Apache Bugzilla)
The fix made by the project is simplistic and achieves the goal. At any point during code execution, should the value of "payloadLength" drop below zero, the fixed versions now throw an error and terminate further processing of the payload.
Image: The fix made to the Apache Websocket project now checks the `payloadLength` value properly (via GitHub)
Customers of Sonatype benefitted from the following information as soon as this vulnerability was disclosed publicly. Our Security Research team was quick to expedite our complete deep dive research on the vulnerability, which was then published to Sonatype Intelligence and all of our products.
Sonatype's explanation
The `tomcat-websocket` package is vulnerable to a Denial of Service (DoS). The `processRemainingHeader` method in `WsFrameBase.java` expects the most significant bit of the payload length to be 0, otherwise, it gets taken as a negative number and is then endlessly processed. A remote attacker could exploit this behavior with several malicious requests that end up in such a situation to cause a DoS situation.
Our recommendation
We recommend upgrading to a version of this component that is not vulnerable to this specific issue.
Users of Tomcat Websocket versions:
10.x should upgrade to 10.0.0-M7
9.x should upgrade to 9.0.37
8.x should upgrade to 8.5.57
7.x should upgrade to 7.0.105
Note: If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or a potential mitigating control.
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of malicious intent. Sonatype customers were notified of this vulnerability within hours of the discovery and their development teams automatically received instructions on how to remediate the risk.
If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Sonatype Vulnerability Scanner to quickly find out.
Visit the Sonatype Intelligence Insights page for a deep dive into other vulnerabilities like this one. Or subscribe to automatically receive Sonatype Intelligence Insights hot off the press.
