Bandit: Unauthenticated DoS via chunked request trailers in Bandit HTTP/1 decoder

Laag (49/100): monitoren. Zwaarst wegend: technische ernst en betrouwbaarheid van het signaal.

De priority_score is de Action Urgency Score: een gewogen combinatie van de technische ernst, de exploitatie en de gemeentelijke relevantie.

### Summary A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a `Transfer-Encoding: chunked` request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic. The vulnerability was likely introduced with this commit on `Dec 6, 2024`: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217 ### Details The bug is in `lib/bandit/http1/socket.ex` in `do_read_chunked_data!/5` (around lines 242–274). The terminator clause matches only `["0", "\r\n" <> rest]` — i.e. the last-chunk line `0\r\n` followed *immediately* by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between `0\r\n` and the final `\r\n`, e.g. a body ending `0\r\nX-T: v\r\n\r\n`. When trailers are present, `:binary.split/2` returns `["0", "X-T: v\r\n\r\n"]`. The terminator clause does not match. The inner `<<_::binary-size(0), ?\r, ?\n, _::binary>>` pattern also does not match because `rest` starts with `X`. Execution falls into the `_ ->` arm, which computes `to_read = 0 - byte_size(rest)` (a negative number) and calls `read_available!/2` on the socket. On timeout, `read_available!/2` returns `<<>>`, leaving the buffer unchanged. `do_read_chunked_data!/5` then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection. The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and `read_available!` is repeatedly called with no progress. The gap is acknowledged in the source itself — the comment on line 245 reads: *"We should be reading (and ignoring) trailers here"*. **Suggested fix:** after the `0` size line, consume bytes up to `\r\n\r\n` (parsing/discarding trailers via `:erlang.decode_packet(:httph_bin, …)`) before returning. Additionally, ensure every recursive arm makes forward progress — when `read_available!/2` returns `<<>>`, raise `request_error!(:request_timeout)` rather than re-entering with an unchanged buffer. ### PoC A self-contained reproduction script is available below. It starts Bandit 1.10 on `127.0.0.1:4321` with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is: - one 5-byte chunk `"hello"` - the last-chunk marker `0\r\n` - one trailer field `X-Trailer: 1\r\n` - the terminating `\r\n` The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, `:gen_tcp.recv/3` times out after 10 seconds because the worker is stuck spinning in `do_read_chunked_data!/5`. Steps to reproduce: 1. `elixir script.exs` 2. Observe the `TIMEOUT — worker is pinned in do_read_chunked_data!/5` log line. 3. Each additional concurrent client sending the same request consumes one more worker process. ### Impact Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement. ### Script and Logs ```elixir # Bandit HTTP/1 chunked decoder hangs on requests with trailer headers. # # lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates # only when the last-chunk line `0\r\n` is followed *immediately* by the # empty trailer line `\r