Am I affected?

type your grpc_server version to check

Description

Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc_server 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 (grpc_server/lib/grpc/server/adapters/cowboy/handler.ex) never checks the configured max_body_size. Only the unary read path enforces that cap. 'Elixir.GRPC.Server.Adapters.Cowboy':reading_stream/1 (grpc_server/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 grpc_server: from 1.0.0 before 1.0.6.

Technical analysis

1. The cap applies to unary reads only

The commit that added max_body_size checks it in read_full_body/4, which serves unary requests through the {:read_full_body, ref, pid} clause of 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':info/3. The {:read_body, 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':reading_stream/1 reads chunks through that clause and appends each one to a binary buffer. It emits a message only when GRPC.Message.get_message/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 END_STREAM makes the buffer grow without limit. The BEAM eventually runs out of memory and the node crashes.

Proof of concept

  1. Start a grpc_server 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 END_STREAM, well past the configured max_body_size.
  4. Observe that the server buffers all of it and server memory grows. The equivalent unary call is rejected with RESOURCE_EXHAUSTED.

Weaknesses & attack patterns

Weakness

CWE-770 · Allocation of Resources Without Limits or Throttling in catalog → MITRE ↗

Attack patterns

CAPEC-130 · Excessive Allocation MITRE ↗

An unauthenticated client can crash a grpc_server node through one streaming RPC connection. This takes down every service on that node.

Affected — Hex / grpc_server Hex.pm ↗ Repository ↗

≥ 1.0.0 < 1.0.6 affected
every other version: unaffected
cpe cpe:2.3:a:elixir-grpc:grpc_server:*:*:*:*:*:*:*:*
version type semver
modules · source files · routines
modules 'Elixir.GRPC.Server.Adapters.Cowboy.Handler' · 'Elixir.GRPC.Server.Adapters.Cowboy'
source files lib/grpc/server/adapters/cowboy/handler.ex · lib/grpc/server/adapters/cowboy.ex
routines 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':info/3 · 'Elixir.GRPC.Server.Adapters.Cowboy':reading_stream/1

Affected — GitHub / elixir-grpc/grpc Repository ↗

≥ 49e18c3 < 0b663ca affected
every other version: unaffected
cpe cpe:2.3:a:elixir-grpc:grpc_server:*:*:*:*:*:*:*:*
version type git
modules · source files · routines
modules 'Elixir.GRPC.Server.Adapters.Cowboy.Handler' · 'Elixir.GRPC.Server.Adapters.Cowboy'
source files grpc_server/lib/grpc/server/adapters/cowboy/handler.ex · grpc_server/lib/grpc/server/adapters/cowboy.ex
routines 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':info/3 · 'Elixir.GRPC.Server.Adapters.Cowboy':reading_stream/1

Configurations

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

References

Credits

Arpit Jain Finder Reporter Remediation developer
Paulo Valente Remediation reviewer
Jonatan Männchen / EEF Coordinator

CVSS breakdown

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
« All CVEs