Transfer-Encoding accepts non-OWS whitespace before "chunked" (TE.CL smuggling vector)

[oalders]

Split out from #56 / CVE-2022-31081 (POC #7).

Per RFC 9110 §5.6.3:

OWS = *( SP / HTAB )

Only SP and HTAB are permitted as optional whitespace around a field-line value.

HTTP::Daemon's header-value parse at lib/HTTP/Daemon.pm:166 strips \s* after the colon — which in Perl includes TAB, form feed (\x0c), and vertical tab (\x0b). So Transfer-Encoding: \x0cchunked normalizes to chunked and triggers chunked decoding at lib/HTTP/Daemon.pm:212:

if ($tr_enc && lc($tr_enc) eq 'chunked') {

Per RFC 9112 §6.1, Transfer-Encoding = #transfer-coding — a comma-separated list of bare tokens with no internal whitespace. RFC 9112 §6.1 further states:

A server that receives a request message with a transfer coding it does not understand SHOULD respond with 501 (Not Implemented).

Security relevance

This is the canonical TE.CL smuggling vector documented in PortSwigger's HTTP Desync Attacks: Request Smuggling Reborn. A frontend that treats Transfer-Encoding: \x0cchunked as unrecognized (and falls back to Content-Length framing) while HTTP::Daemon decodes it as chunked produces a desync — attacker bytes beyond the chunked body are read by the frontend as the start of the next pipelined request.

Proposed fix

1. Tighten header-value extraction to use [ \t]* rather than \s* (overlaps with Header parser accepts whitespace before colon, violating RFC 9112 §5.1 #84).
2. Validate the parsed Transfer-Encoding value against the RFC 9112 §6.1 grammar before matching chunked at Daemon.pm:212 — i.e. parse it as a comma-separated list of transfer-coding tokens and check exact match (case-insensitive) on each, rather than lc($tr_enc) eq 'chunked' on the raw value.

[oalders]

This note arose from an adversarial review of the issue — corrections and added context below.

• The phrase "canonical TE.CL smuggling vector documented in PortSwigger" is an overstatement. Kettle's HTTP Desync Attacks enumerates many Transfer-Encoding obfuscations, but does not specifically single out a leading form feed / vertical tab before the value. The general class is well-known; this exact variant is a plausible instance, not the textbook example.
• More precisely: the bug is the \s* immediately after the colon on lib/HTTP/Daemon.pm:166, which consumes a leading \x0c / \x0b / \t before chunked.
• Important for whoever implements the fix: when Transfer-Encoding is present but unrecognized, the daemon must not fall back to Content-Length framing. Per RFC 9112 §6.3, Transfer-Encoding overrides Content-Length; the correct response is 400 (§6.3) or 501 (§6.1). Silently using CL preserves the desync.
• Minor: transfer-coding per RFC 9112 §7 permits ;parameter extensions (e.g. chunked;foo=bar). A strict per-token eq 'chunked' check would reject those — rare in practice, but the grammar allows it, so the validation should match the coding name and tolerate parameters.