Ember's HTTP/2 stack replenishes the inbound flow-control window based on bytes
received off the wire, not bytes consumed by the application. Received DATA is buffered in an unbounded per-stream channel. Flow control therefore
provides no backpressure: a peer can stream a large or unbounded body faster than the application drains it and the connection retains every payload in heap.
This is the read-path mirror of the outbound queue issue.
This affects an Ember receiving a request body and an Ember client receiving a response body from a hostile server.
Impact
Unauthenticated remote denial of service (OOM) against any Ember server built
.withHttp2 for a non-draining or slow-draining route, and against an Ember client consuming from a hostile or compromised server.
Workarounds
- Disable HTTP/2 to remove the vector entirely.
- Apply an aggregate request-entity size limit (e.g.
EntityLimiter middleware) on routes that consume the body.
- Ensure handlers fully drain request bodies with aggressive idle timeouts.
References
rossabaker Analyst
reardonj Remediation reviewer
Ember's HTTP/2 stack replenishes the inbound flow-control window based on bytes
received off the wire, not bytes consumed by the application. Received DATA is buffered in an unbounded per-stream channel. Flow control therefore
provides no backpressure: a peer can stream a large or unbounded body faster than the application drains it and the connection retains every payload in heap.
This is the read-path mirror of the outbound queue issue.
This affects an Ember receiving a request body and an Ember client receiving a response body from a hostile server.
Impact
Unauthenticated remote denial of service (OOM) against any Ember server built
.withHttp2for a non-draining or slow-draining route, and against an Ember client consuming from a hostile or compromised server.Workarounds
EntityLimitermiddleware) on routes that consume the body.References