Listen to this Post
The core vulnerability lies in Netty’s `HttpObjectDecodergetChunkSize` method, which parses HTTP chunked encoding sizes. The method calculates the chunk length by accumulating each hexadecimal digit: result = 16; result += digit;. Critically, the integer overflow is not checked. The code only checks if the final `result` is negative. By providing an extremely large, specially-crafted chunk size (e.g., `0x100000004` which is 4,294,967,300 bytes), the multiplication and addition cause the `int` variable to overflow. When processed, `0x100000004` overflows back to a small, valid hexadecimal value. This causes Netty to misinterpret the boundaries of the HTTP message. An attacker can embed a complete, second HTTP request inside what Netty believes is the data of a single chunk. The vulnerable code, prior to version 4.1.44.Final, fails to reject these oversized values, leading to a classic HTTP Request Smuggling scenario. The following Proof-of-Concept demonstrates the smuggling of a `GET /smuggled` request within a chunked request body, which Netty successfully parses as two separate requests.
@Test
public void test() {
String requestStr = "POST / HTTP/1.1\r\n" +
"Host: localhost\r\n" +
"Transfer-Encoding: chunked\r\n\r\n" +
"100000004\r\n" + // Overflowing chunk size
"test\r\n" +
"0\r\n" +
"\r\n" +
"GET /smuggled HTTP/1.1\r\n" +
"Host: localhost\r\n" +
"Content-Length: 0\r\n" +
"\r\n";
EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));
// Request 1
HttpRequest request = channel.readInbound();
assertTrue(request.decoderResult().isSuccess());
// ... The smuggled 'GET /smuggled' request is parsed as a second message.
// Request 2
request = channel.readInbound();
assertTrue(request.decoderResult().isSuccess());
}
DailyCVE Form:
Platform: Netty Framework
Version: Before 4.1.44.Final
Vulnerability : HTTP Request Smuggling
Severity: Critical 9.1
date: 2020-01-29
Prediction: Patch date 2020-02-14
What Undercode Say:
Analytics: This vulnerability has a CVSS v3 base score of 9.1 (Critical) with the vector CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. The attack vector is network-based, requires low attack complexity, and no privileges or user interaction. The impact on both confidentiality and integrity is high. The vulnerability is trivial to exploit, with public exploit code available. This is a high-priority patch for any organization using Netty in a reverse proxy or web server capacity. The exploitation of the integer overflow effectively bypasses normal HTTP message parsing, enabling cache poisoning and session hijacking.
Bash commands / Codes:
To check your Netty version and see if it’s vulnerable:
Check Netty version if running from a JAR: grep -i "netty-buffer" /path/to/your/application.jar For Maven projects, check your pom.xml: grep "netty" pom.xml A vulnerable version output example: <version>4.1.42.Final</version>
To test your own endpoint’s vulnerability (use only on authorized systems):
curl -X POST http://[bash]/ \ -H "Transfer-Encoding: chunked" \ --data-binary @payload.txt Where payload.txt contains the crafting request.
Exploit:
An attacker sends a single HTTP request with a `Transfer-Encoding: chunked` header followed by a chunk size of `0x100000004` (or 4294967300 in decimal). Netty’s parser calculates the size as an integer, which overflows. The parser incorrectly determines that the chunk contains only a small amount of data. After reading that small amount, it treats the remaining text—which is actually a complete, second HTTP request (e.g., GET /admin HTTP/1.1)—as a brand new request. The smuggled request bypasses security controls and is processed by the backend server, potentially allowing an attacker to steal data or perform unauthorized actions.
Protection from this CVE:
The primary mitigation is to upgrade Netty to version 4.1.44.Final or later, where the integer overflow is correctly detected and rejected. If an immediate upgrade is impossible, a workaround is to use HTTP/2 (which does not use chunked encoding in the same way) or to configure your network to not reuse backend connections (e.g., `http-reuse never` in HAProxy), as request smuggling relies on connection reuse.
Impact:
Successful exploitation leads to HTTP Request Smuggling. An attacker can poison web caches, bypass web application firewall protection, perform cross-site scripting (XSS) attacks, and directly access or manipulate backend systems that are otherwise unreachable from the outside. In high-impact scenarios, this can lead to full account takeover, data theft, and complete compromise of back-end services.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
