Am I affected?

type your bandit version to check

Description

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to hold stream processes open indefinitely via WINDOW_UPDATE or empty SETTINGS frames sent while a Plug reads the request body.

Bandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. A stream WINDOW_UPDATE, or the zero-delta window update that every empty SETTINGS frame delivers to all streams, ends the wait without delivering any body data, and the loop starts a new full countdown. A client that sends one of these 9-byte frames before each countdown expires keeps read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.

This issue affects bandit: from 1.4.0 before 1.14.0.

Technical analysis

1. Per-receive timeout. Bandit.HTTP2.Stream.read_data/2 passes a flat read_timeout (default 15,000 ms) to do_read_data/4, which blocks in do_recv/2's receive ... after timeout.

2. Non-progress frames end the wait. A stream WINDOW_UPDATE, delivered through Bandit.HTTP2.Connection.handle_frame/3, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that receive. do_recv_send_window_update/2 returns a bare %Stream{}, and do_read_data/4 recurses with the identical timeout, restarting the countdown.

3. Nothing else bounds the read. The transport read timeout fires only when no bytes arrive, max_bytes is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in do_send_data/4 uses a progress-based deadline; the read path does not.

Proof of concept

  1. Run Bandit with a Plug that calls Plug.Conn.read_body/2.
  2. Open an HTTP/2 connection and send HEADERS for POST / on stream 1 without END_STREAM.
  3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.
  4. The stream stays open for 120 s, eight times the default 15 s read_timeout. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s.

Weaknesses & attack patterns

Weakness

CWE-835 · Loop with Unreachable Exit Condition ('Infinite Loop') in catalog → MITRE ↗
CWE-770 · Allocation of Resources Without Limits or Throttling in catalog → MITRE ↗

Attack patterns

CAPEC-469 · HTTP DoS MITRE ↗

An unauthenticated client can keep a Bandit HTTP/2 stream, and whatever its request handler holds while reading the body, occupied indefinitely for 9 bytes per read_timeout, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH.

Affected — Hex / bandit Hex.pm ↗ Repository ↗

≥ 1.4.0 < 1.14.0 affected
every other version: unaffected
cpe cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*
version type semver

Affected — GitHub / mtrudel/bandit Repository ↗

≥ fff06ef < 220b9df affected
every other version: unaffected
cpe cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*
version type git

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable read path never runs.

References

Credits

Peter Ullrich Analyst
Daniel Coles Reporter
Mat Trudel Remediation developer
Jonatan Männchen / EEF Analyst

CVSS breakdown

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
« All CVEs