GHSA-vx6q-cr5q-945g: Unbounded request body accumulation on streaming RPCs causes memory exhaustion in grpc_server
Summary
Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpcserver allows unauthenticated attackers to exhaust memory and crash the node via an oversized client-streaming or bidirectional-streaming request body.
The streaming read clause of 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':info/3 (grpcserver/lib/grpc/server/adapters/cowboy/handler.ex) never checks the configured maxbodysize. Only the unary read path enforces that cap. 'Elixir.GRPC.Server.Adapters.Cowboy':readingstream/1 (grpcserver/lib/grpc/server/adapters/cowboy.ex) appends every received chunk to its buffer until a complete length-prefixed message arrives. A client can declare a very large message and send it across many small HTTP/2 DATA frames, and the server buffers all of it.
This issue affects grpcserver: from 1.0.0 before 1.0.6.
Details
1. The cap applies to unary reads only
The commit that added maxbodysize checks it in readfullbody/4, which serves unary requests through the {:readfullbody, ref, pid} clause of 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':info/3. The {:readbody, ref, pid} clause, which serves streaming requests, returns each chunk to the caller with no size check.
2. Unbounded buffering
'Elixir.GRPC.Server.Adapters.Cowboy':readingstream/1 reads chunks through that clause and appends each one to a binary buffer. It emits a message only when GRPC.Message.getmessage/1 finds a complete length-prefixed gRPC message in the buffer. Until then, the buffer grows with every chunk.
3. Memory exhaustion
A client that declares a large message length and keeps sending DATA frames without ENDSTREAM makes the buffer grow without limit. The BEAM eventually runs out of memory and the node crashes.
Proof of concept
1. Start a grpcserver endpoint that exposes a client-streaming or bidirectional-streaming RPC method. 2. Open an HTTP/2 connection and send a request to that method. 3. Send the request body across many small HTTP/2 DATA frames without ENDSTREAM, well past the configured maxbodysize. 4. Observe that the server buffers all of it and server memory grows. The equivalent unary call is rejected with RESOURCEEXHAUSTED.
Impact
An unauthenticated client can crash a grpcserver node through one streaming RPC connection. This takes down every service on that node.
Configurations
The server must expose at least one client-streaming or bidirectional-streaming RPC method.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/grpc_serverto a version that resolves this vulnerability.Fixed in 1.0.6 - Upgrade
Upgrade
elixir-grpc/grpc_serverto a version that resolves this vulnerability.Fixed in 1.0.6
Event History
Frequently Asked Questions
Which deployments are exposed?
grpc_server versions from 1.0.0 before 1.0.6 are affected when they accept client-streaming or bidirectional-streaming RPC requests. Unary RPC reads enforce max_body_size and are not the vulnerable path described.
What does an attacker need to do to trigger the issue?
An unauthenticated attacker needs to send a client-streaming or bidirectional-streaming request that declares a very large length-prefixed message and delivers it in many small HTTP/2 DATA frames. The server appends the chunks until the complete message arrives, allowing memory exhaustion and a node crash.
Does configuring max_body_size protect streaming RPCs?
No. The configured max_body_size is checked on the unary read path, but the streaming read path does not check it.
What can be done if upgrading is not immediately possible?
The provided information does not identify a configuration-only mitigation for the affected streaming path. Restricting unauthenticated access to client-streaming and bidirectional-streaming RPC endpoints can reduce exposure until upgrading to 1.0.6 or later.