Database/Container, Kubernetes & orchestration

Kyverno: 3DES cipher suites offered on TLS endpoints expose long-lived sessions to Sweet32

CVE-2023-54356Container, Kubernetes & orchestrationcurated

Impact

Kyverno 1.9.4 and earlier offer TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_3DES_EDE_CBC_SHA on their TLS endpoints. These are 64-bit block ciphers, so a Sweet32 birthday attack can recover small amounts of plaintext, but only against a single connection that stays open and carries a very large volume of traffic. In a cluster the peer on those endpoints is the kube-apiserver talking to the admission webhook, so the realistic exposure is an on-path attacker inside the cluster network watching admission traffic rather than anything reachable from outside. Treat this as cipher-suite hygiene on the admission path, not as a route to code execution - the CVSS 4.0 score in the record is far above what the described conditions support.

Who can reach it

An attacker who can observe or sit on the pod-network path between kube-apiserver and the Kyverno webhook service, and who can keep a single TLS connection alive long enough to move hundreds of gigabytes through it. No credentials are needed, but network position is.

What to do

Upgrade Kyverno to 1.9.5 or 1.10.0 or later and roll the Kyverno deployment; the cipher list is compiled in, so a restart of the pods is the whole rollout. No node drain or reboot. If you are already on a current Kyverno release this is closed for you.

References

https://nvd.nist.gov/vuln/detail/CVE-2023-54356 https://github.com/kyverno/kyverno/security/advisories/GHSA-hgv6-w7r3-w4qw https://www.vulncheck.com/advisories/kyverno-before-1.9.5-sweet32-medium-strength-cipher-suites

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.