HTTP/2 request bodies made of 1-byte DATA frames amplify memory use in Bandit

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a request body sent as many 1-byte DATA frames.

do_read_data/5 in lib/bandit/http2/stream.ex keeps every DATA frame payload as its own list element until the read returns. The :length option of read_body/2 counts body bytes, not frames, so a body of 1-byte frames costs a list cell and a binary term per byte. Interleaving the frames across up to 500 concurrent streams per connection keeps each stream consuming its frames as they arrive; in the reporter's test, 100 streams held 25 to 40 MiB of stream process memory for 5 MB sent. Only routes whose Plug reads the request body are affected, which includes any route behind Plug.Parsers.

This issue affects bandit: from 0.3.1 before 1.14.1.

Details

1. Per-frame accumulation. Bandit.HTTP2.Stream.read_data/2 calls do_read_data/5 in lib/bandit/http2/stream.ex, which prepends each {:data, data, stream} payload to a list ([data | acc]) and reverses it when the read returns. Each 1-byte payload arrives as a separate message from the connection process, so the stream heap holds a cons cell and a heap binary per frame.

2. Byte-only limit. :length (default 8,000,000) is decremented by byte_size(data) and bounds body bytes, not the number of frames. A read ends at :length or at its read_timeout deadline, and 1-byte frames add no measurable deadline credit, so a stream holds whatever arrives within the deadline at the per-frame overhead ratio. Plug.Parsers answers 413 on :more, and the client continues on a new stream.

3. Interleaving defeats connection buffering. The connection buffers DATA for a stream only once that stream has 16 messages outstanding. A stream that keeps up never reaches this, and interleaving one frame per stream per round across many streams keeps every stream under it regardless of TCP segment size.

4. Measurements on 1.14.0. 100 streams of 5,000 interleaved 1-byte frames (5,000,000 bytes on the wire, 488 KiB of body) held 25 to 40 MiB in stream processes, with empty mailboxes. One stream of 60,000 frames sent one per write held 2 to 4 MiB for 58 KiB of body.

Proof of concept

1. Run Bandit with HTTP/2 enabled and a Plug that calls Plug.Conn.read_body(conn) with default options.
2. Open an h2c connection, exchange prefaces and SETTINGS, and send HEADERS for POST / without END_STREAM on 100 streams (IDs 1, 3, 5, ...).
3. Send 5,000 rounds of 1-byte DATA frames, one frame per stream per round, batched into writes of 100 frames.
4. Three seconds later, while the reads are still open, the 100 stream processes hold 25 to 40 MiB combined with empty mailboxes, for about 5 MB sent.

Impact

An unauthenticated client can make a Bandit HTTP/2 server hold about 5 to 8 times the bytes it sends in stream process memory, across up to 500 streams per connection and many connections, for as long as each body read runs. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH.

Workarounds

From 0.7.0, disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable body reader never runs.