[Security Advisory] CVE-2024-7598: Network restriction bypass via race condition during namespace termination

Announcements
1

Hello Kubernetes Community,

A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.

This issue has been rated Low (3.1) CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N, and assigned CVE-2024-7598.

Am I vulnerable?

All clusters that rely on the NetworkPolicy API may be vulnerable. Run the following command to see if network policies are in use:

kubectl get networkpolicies.networking.k8s.io --all-namespaces

Affected Versions

  • kube-apiserver >= v1.3

How do I mitigate this vulnerability?

This issue can be mitigated by:

  • Manually deleting pods and workload resources that orchestrate pods before starting namespace deletion

  • Adding finalizers to network policies to prevent them from being deleted until the pods that they protect have been deleted first. The following proof-of-concept controller automates this process:

  • https://github.com/kubernetes-sigs/network-policy-finalizer

Fixed Versions

Detection

Users of network policies may be able to detect abuse via network logs. The exact details of this process are environment specific.

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/126587

Acknowledgements

This vulnerability was reported by John McGuinness @s1xtw03 and Aaron Coffey @aaroncoffey.

The issue was coordinated by:

Antonio Ojea @aojea

Tim Hockin @thockin

Dan Winship @danwinship

Shane Utt @shaneutt

David Eads @deads2k

Clayton Colemon @smarterclayton

Mo Khan @enj

Craig Ingram @cji

Thank You,

Craig Ingram on behalf of the Kubernetes Security Response Committee