Summary
Apache Tomcat is an open source Java Servlet and JavaServer Pages (JSP) container developed and maintained by the Apache Software Foundation. As a lightweight, fast, and scalable web server, it is used to execute Java Servlets and JavaServer Pages technologies.
Tomcat can function as a standalone server, serving as a web server for Java applications, or it can be integrated as a Servlet container into other web servers (such as the Apache HTTP Server). It handles HTTP requests, forwards them to the corresponding Servlet or JSP for processing, then returns the results to the client.
Tomcat provides various features, including connection pooling, session management, security, Web application deployment, load balancing, and more. It is a popular deployment environment for enterprise-level Java web applications and is widely used for developing and deploying Java Web applications and services.
The author selected the common vulnerabilities of Tomcat component to analyze by analyzing hundreds of real project components introduced. This analysis is CVE-2022–42252, the vulnerability is Tomcat’s rejectIllegalHeader configuration is False, Tomcat will not reject the request containing invalid Content-Length header, if Tomcat is located behind the reverse proxy, and the reverse proxy can not reject requests with invalid headers, then a request smuggling attack may occur. request with an invalid header, a request smuggling attack may occur.
tomcat-embed-core is part of the Apache Tomcat project and is a library for embedding the Tomcat kernel in Java applications. tomcat-embed-core allows you to embed Tomcat as an embedded container in your Java applications in order to run web applications inside the application.
Information
·Name：Request Smuggling Vulnerability
·Number：CVE-2022–42252
·Type：CWE-444 HTTP Request/Response Smuggling
·CVSS Score：CVSS v3.1：7.5
·Severity Level：high
This vulnerability exploits the fact that Tomcat does not reject requests containing an invalid Content-Length header when the rejectIllegalHeader attribute of connect in conf/server.xml is false, and if Tomcat is behind a reverse proxy that is also unable to reject requests with invalid headers, a request smuggling attack may occur. If Tomcat is behind a reverse proxy that is also unable to reject requests with invalid headers, then a request smuggling attack may occur.
The affected versions are as follows
Apache Tomcat 10.1.0-M1–10.1.0
Apache Tomcat 10.0.0-M1–10.0.26
Apache Tomcat 9.0.0-M1–9.0.67
Apache Tomcat 8.5.0–8.5.52
Technical Analysis
1. HTTP Request Smuggling
HTTP request smuggling is a technique to interfere with the way a website processes sequences of HTTP requests received from one or more users. Request smuggling vulnerabilities are generally highly severe as they allow attackers to bypass security controls and gain unauthorized access to sensitive data, directly compromising other application users.
When a frontend server forwards HTTP requests to a backend server, it typically sends multiple requests over the same backend network connection as this is much more efficient and performant. The protocol is very simple: HTTP requests are sent one after the other, and the receiving server parses the HTTP request headers to determine where one request ends and the next one begins:
In this case, it is crucial that the frontend and backend systems agree on the boundaries between requests. Otherwise, attackers may be able to send ambiguous requests that are interpreted differently by the frontend and backend systems:
Here, the attacker causes a portion of the front-end request to be interpreted by the back-end server as the start of the next request. Before it is effectively added to the next request, it may interfere with the way the application handles that request. This is a request smuggling attack and can have disastrous consequences.
The HTTP specification provides two different ways to specify the end of a request: Content-Length and Transfer-Encoding.
When both HTTP headers are present, the Content-Length header should be ignored according to the HTTP specification. However, if some servers do not support the Transfer-Encoding header or the header is obfuscated and the server does not handle the Transfer-Encoding header, a request smuggling vulnerability can occur.
Conducting an HTTP request smuggling attack can place both Content-Length and Transfer-Encoding heade in a single HTTP request so that the front-end and back-end servers handle the request in different ways.
2. CVE-2022–42252
The information about the vulnerability on nvd shows that the vulnerability is caused by Tomcat not rejecting the Content-Length header in a configuration where rejectIllegalHeader is false.
Looking at the patch code:
It was found that when the value of the Content-Length header of the headers contained a control character the line header was removed and then parsed normally.
And in the patched skipLine function, if the header to be removed is Content-Length, then it will set rejectThisHeader to true, and instead of removing the header, it will throw an exception.
It can be guessed that if the server on the front-end had not rejected the illegal Content-Length header, and the Tomcat back-end before the fix would have removed the header for a normal response, this would have created the possibility of request smuggling.
Reproduction
Modify the connector configuration in conf/server.xml:
<Connector port=”8080" protocol=”HTTP/1.1"
connectionTimeout=”20000"
redirectPort=”8443" rejectIllegalHeader=”false” />
Send the PoC:
POST / HTTP/1.1
Host: <host>:8080
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.78 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Content-Length: 12\x00073 # \x0007 needs to be modified in hex mode
See the handling of Content-Length.
Before removeHeader:
After removeHeader:
The response is then processed normally and a response code of 200 is returned. According to RFC 7230, if the value of the Content-Length header does not conform to the specification or if the header cannot be parsed properly, an error response of 400 should be returned.
Fix
There are several ways to fix this vulnerability:
1. Upgrade Tomcat to a version without the vulnerability
- Update Apache Tomcat >= 10.1.1
- Update Apache Tomcat >= 10.0.27
- Update Apache Tomcat >= 9.0.68
- Update Apache Tomcat >= 8.5.83
The official Tomcat fix adds an extra validation in the skipLine method, if it is because of the current processing of the header for the Content-Length will rejectThisHeader set to true, not to remove the header but to throw an exception and return a 400 error page.
2. Set rejectIllegalHeader to true
rejectIllegalHeader defaults to false in 8.5.x. Setting it to true will cause errors when handling illegal headers.
3. Interception using WAF etc.
Since this vulnerability relies on Tomcat as a backend server, the HTTP request could be rejected or intercepted by the frontend before reaching Tomcat.
