HTTP header parser incorrectly accepts CR and NUL within header values

[kenballus]

Environment Details

• GlassFish Version (and build number): master at 2d9ff32
• JDK version: openjdk 21.0.4 2024-07-16
• OS: Linux 5c2fd4990cdb 6.10.2-arch1-2 #1 SMP PREEMPT_DYNAMIC Sat, 03 Aug 2024 17:56:17 +0000 x86_64 GNU/Linux

---

Problem Description

From RFC 9110:

Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.

Glassfish does not enforce this rule for CR and NUL.

Steps to reproduce

1. Start a Glassfish server that echoes back received header names, such as this one.
2. Send it a request with NUL and CR within a header value, and observe that the CR and NUL are processed, despite being forbidden by the RFC:¹

printf 'GET / HTTP/1.1\r\nHost: whatever\r\nTest: \x00\ra\r\n\r\n' \
  | timeout 1 ncat --no-shutdown localhost 80 \
  | grep '"headers"' \
  | jq '.["headers"][1][1]' \
  | xargs echo \
  | base64 -d \
  | xxd

00000000: 000d                                     ..

Impact of Issue

Mishandling of NUL and CR have been used as primitives in parsing discrepancy-related attacks, such as request smuggling, response splitting, and some forms of cache poisoning.

Footnotes

1. One interesting thing here is that the a byte after the CR is not interpreted by the parser. I'm not sure what's causing this, but it could be indicative of a second parsing problem. ↩

[OndroMih]

The link to the example servlet Server.java that echoes back received header names is broken, here's the correct link: https://github.com/narfindustries/http-garden/blob/6608a547d814943dd6271ad1ccd67cf91cecb965/images/eclipse_glassfish/Server.java

[kenballus]

Thanks for the follow-up. I'm actually going to close this issue, because this bug is caused by an underlying bug in Grizzly. This is also why the link was broken; I have stopped fuzzing Glassfish and have begun fuzzing Grizzly directly.

Seems like someone probably noticed this, because a couple weeks after I made this issue, someone opened a corresponding one in Grizzly: eclipse-ee4j/grizzly#2212