GHSA-rj35-4m94-77jh
Envoy forwards early CONNECT data in TCP proxy mode
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Go | github.com/envoyproxy/envoy | >= 1.36.0, < 1.36.3 | 1.36.3 |
| Go | github.com/envoyproxy/envoy | >= 1.35.0, < 1.35.7 | 1.35.7 |
| Go | github.com/envoyproxy/envoy | >= 1.34.0, < 1.34.11 | 1.34.11 |
| Go | github.com/envoyproxy/envoy | < 1.33.13 | 1.33.13 |
Details
As written in the advisory (Markdown source, shown as plain text).
## Summary
Forwarding of early CONNECT data in TCP proxy mode.
## Details
Per [RFC 7231-4.3.6](https://www.rfc-editor.org/rfc/rfc7231#section-4.3.6) the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.
The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the `envoy.reloadable_features.reject_early_connect_data` runtime flag to `true` will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.
## Impact
De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.
## Attack vector(s)
Sending data for a CONNECT request before receiving 2xx response.
## Patches
Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13
## Credits
[chasingimpact](https://github.com/chasingimpact) (Patrick)
References
External links from the advisory. They lead to third-party sites.