Impact
Alex Brand from VMware has discovered a denial of service (DOS) vulnerability in Contour's deployment of Envoy where a bad actor can shut down all instances of Envoy, essentially killing the entire ingress data plane.
The vulnerability was immediately fixed by the Contour team.
Issue
GET requests to /shutdown on port 8090 of the Envoy pod initiate Envoy’s shutdown procedure. The shutdown procedure includes flipping the readiness endpoint to false, which removes Envoy from the routing pool.
When running Envoy (For example on the host network, pod spec hostNetwork=true), the shutdown manager’s endpoint is accessible to anyone on the network that can reach the Kubernetes node that’s running Envoy. There is no authentication in place that prevents a rogue actor on the network from shutting down Envoy via the shutdown manager endpoint.
Note that this is an issue with the deployment method of Envoy, not a code issue with Envoy or Contour.
Known Attack Vectors
Successful exploitation of this issue will lead to bad actors shutting down all instances of Envoy, essentially killing the entire ingress data plane.
Patches
If your product uses the affected releases of Contour, update to version 1.7.0 immediately.
https://github.com/projectcontour/contour/releases/tag/v1.7.0
Workarounds
There is no known workaround.
Fix details
The preStop lifecycle hook now uses a command instead of an http request. The /shutdown http endpoint now only returns when the pod is ready to be terminated, and no longer initiates the Envoy shutdown sequence.
The Envoy container will block on its preStop hook until the /shutdown endpoint returns. That endpoint, implemented in the shutdown-manager, will utilize a file messaging pattern to know when it is safe for Envoy to terminate by checking for the existence of a file in the filesystem.
For more information
If you have any questions or comments about this advisory, contact cncf-contour-maintainers@lists.cncf.io
View our security policy at https://github.com/projectcontour/contour/security/policy
Impact
Alex Brand from VMware has discovered a denial of service (DOS) vulnerability in Contour's deployment of Envoy where a bad actor can shut down all instances of Envoy, essentially killing the entire ingress data plane.
The vulnerability was immediately fixed by the Contour team.
Issue
GET requests to /shutdown on port 8090 of the Envoy pod initiate Envoy’s shutdown procedure. The shutdown procedure includes flipping the readiness endpoint to false, which removes Envoy from the routing pool.
When running Envoy (For example on the host network, pod spec hostNetwork=true), the shutdown manager’s endpoint is accessible to anyone on the network that can reach the Kubernetes node that’s running Envoy. There is no authentication in place that prevents a rogue actor on the network from shutting down Envoy via the shutdown manager endpoint.
Note that this is an issue with the deployment method of Envoy, not a code issue with Envoy or Contour.
Known Attack Vectors
Successful exploitation of this issue will lead to bad actors shutting down all instances of Envoy, essentially killing the entire ingress data plane.
Patches
If your product uses the affected releases of Contour, update to version 1.7.0 immediately.
https://github.com/projectcontour/contour/releases/tag/v1.7.0
Workarounds
There is no known workaround.
Fix details
The preStop lifecycle hook now uses a command instead of an http request. The /shutdown http endpoint now only returns when the pod is ready to be terminated, and no longer initiates the Envoy shutdown sequence.
The Envoy container will block on its preStop hook until the /shutdown endpoint returns. That endpoint, implemented in the shutdown-manager, will utilize a file messaging pattern to know when it is safe for Envoy to terminate by checking for the existence of a file in the filesystem.
For more information
If you have any questions or comments about this advisory, contact cncf-contour-maintainers@lists.cncf.io
View our security policy at https://github.com/projectcontour/contour/security/policy