Client-chosen HPACK encoder table size is applied uncapped, growing per-connection state with every response in Bandit

Overview

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly.

The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process.

This issue affects bandit: from 0.3.6 before 1.14.0.

Affected

• bandit >= 0.3.6 < 1.14.0
• mtrudel/bandit >= 0e68313fab9d204257ebad5c447e4cd9cea8e0ea < 220b9dfd27f9a21305be2afc75cbe585ddc24e7a

Remediation

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

Workarounds

From 0.7.0, cap the requests one HTTP/2 connection may serve, for example with http_2_options: [max_requests: 1000], so each connection and its encoder table is closed before the cost grows large. Alternatively, disable HTTP/2 with http_2_options: [enabled: false].