Streaming request body limit enforced only after an 8 MB read in elixir-grpc grpc_server

Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc_server allows unauthenticated attackers to exhaust server memory via client-streaming or bidirectional-streaming requests.

The streaming read clause of GRPC.Server.Adapters.Cowboy.Handler.info/3 (grpc_server/lib/grpc/server/adapters/cowboy/handler.ex) asks Cowboy for up to 8,000,000 bytes per read and compares the running total with max_body_size only after the read returns. The gRPC length prefix of a message is not checked before the message is buffered. Each stream can therefore buffer up to one full read beyond the configured limit before it is refused, and many concurrent streams exhaust node memory. Releases before 1.0.6 apply no limit to streaming requests at all.

This issue affects grpc_server: from 1.0.0 before 1.1.0.

1. Large reads

async_read_body/2 asks Cowboy for up to 8,000,000 bytes per read on the streaming path, whatever max_body_size is set to.

2. The limit is checked after the read

track_body_bytes/2 adds each returned chunk to a running total and refuses the stream with RESOURCE_EXHAUSTED only once the total exceeds max_body_size. By then the whole chunk is in memory.

3. No check on the length prefix

The 5-byte gRPC prefix can declare up to 4 GiB. The server does not compare it with any limit before buffering, so a prefix that declares an oversized message does not stop the read.

4. Result

Each client-streaming or bidirectional-streaming call can make the server hold several megabytes more than the configured limit, and the attacker can open many such calls at once. Before 1.0.6 the streaming path had no limit, and GRPC.Server.Adapters.Cowboy.reading_stream/1 buffered the whole body.

The server must expose at least one client-streaming or bidirectional-streaming RPC method.