Advisoriesby IbisMissing CR/LF/NUL validation in header values
Summary
SwiftNIO HTTP/2 was missing validation on inbound HEADERS frames that let
CR, LF, NUL, SP and other control characters reach an HTTP/1.1 backend
through NIOHTTP2's HTTP/2-to-HTTP/1 codec, enabling HTTP request smuggling
or response splitting.
Impact
Two related gaps in inbound header validation, against any application
using HTTP2ToHTTP1Codec (or HTTP2FramePayloadToHTTP1Codec) to front an
HTTP/1.1 backend:
Regular header field values were only checked against a forbidden-name
list (connection, transfer-encoding, proxy-connection, keep-alive,
upgrade); the value itself was never inspected. An attacker-controlled
regular header field value containing CR or LF passed validation and, once
serialized as name: value CRLF by the codec, terminated the field early
and injected extra header lines into the outbound HTTP/1.1 message.
Pseudo-header values (:path in particular) were only checked against
CR, LF and NUL. A :path value containing SP serializes into the
request-target of METHOD SP request-target SP HTTP-version CRLF, so a
value like /a HTTP/1.1 produces GET /a HTTP/1.1 HTTP/1.1 — a
parser-differential request line depending on whether a downstream reader
takes the first or last SP-delimited token as the version.
Neither of these is reachable on a stock pipeline: NIOHTTP1's outbound
validator (enableOutboundHeaderValidation, on by default)...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| swift-nio-http2 Product | < 1.45.0 | 1.45.0 |
Details and references
## Summary SwiftNIO HTTP/2 was missing validation on inbound HEADERS frames that let CR, LF, NUL, SP and other control characters reach an HTTP/1.1 backend through NIOHTTP2's HTTP/2-to-HTTP/1 codec, enabling HTTP request smuggling or response splitting. ## Impact Two related gaps in inbound header validation, against any application using HTTP2ToHTTP1Codec (or HTTP2FramePayloadToHTTP1Codec) to front an HTTP/1.1 backend: Regular header field values were only checked against a forbidden-name list (connection, transfer-encoding, proxy-connection, keep-alive, upgrade); the value itself was never inspected. An attacker-controlled regular header field value containing CR or LF passed validation and, once serialized as `name: value CRLF` by the codec, terminated the field early and injected extra header lines into the outbound HTTP/1.1 message. Pseudo-header values (`:path` in particular) were only checked against CR, LF and NUL. A `:path` value containing SP serializes into the request-target of `METHOD SP request-target SP HTTP-version CRLF`, so a value like `/a HTTP/1.1` produces `GET /a HTTP/1.1 HTTP/1.1` — a parser-differential request line depending on whether a downstream reader takes the first or last SP-delimited token as the version. Neither of these is reachable on a stock pipeline: NIOHTTP1's outbound validator (`enableOutboundHeaderValidation`, on by default) already rejects these characters on write. The exposure is pipelines that skip outbound validation, or any code that reads validated-looking `HTTPRequestHead.headers` and forwards the values on trusting that HTTP/2 already checked them. ## Fix Fixed in 48bfd90 and 45bdf67. ## Mitigation Upgrade to 1.45.0
- Severity from
- GitHub (reviewed advisory)