SETTINGS and stream-0 WINDOW_UPDATE frames trigger quadratic work over blocked streams in Bandit

Overview

Inefficient Algorithmic Complexity vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server CPU via small SETTINGS or connection-level WINDOW_UPDATE frames. The attacker opens thousands of streams whose responses block on the connection send window, then sends cheap frames that each make the server walk the whole queue of blocked sends. In the reporter's run, with 3,000 blocked streams a single 9-byte SETTINGS frame took 133 ms to process.

do_pending_sends/2 in lib/bandit/http2/connection.ex retries every queued send and, before each retry, removes that entry from the queue with List.delete/2, so one frame costs O(n²) list operations for n blocked streams. max_concurrent_streams defaults to :infinity, so the attacker chooses n.

This issue affects bandit: from 0.3.4 before 1.14.0.

Affected

• bandit >= 0.3.4 < 1.14.0
• mtrudel/bandit >= 6feadb31189d18b7dcda6c663112cd3bbaf63a46 < 220b9dfd27f9a21305be2afc75cbe585ddc24e7a

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Workarounds

From 1.9.0, bound the number of streams a client can open, for example with http_2_options: [default_local_settings: [max_concurrent_streams: 100]], which bounds the work each frame can cause. From 0.7.0, disabling HTTP/2 with http_2_options: [enabled: false] removes the vulnerable path.