Kyverno versions 1.8.3 and 1.8.4 contained a regression (CVE-2022-47633) which allowed a malicious proxy to facilitate a man-in-the-middle (MiTM) attack allowing an unsigned image to run in a Kubernetes cluster even if there was a Kyverno policy installed to ensure only signed images were permitted. This was due to there being two calls to the registry using the image tag, when there only should have been one, allowing a different digest to be returned on the second call than the first. The issue has been fixed in Kyverno 1.8.5.
On December 14th 2022, Ben Hirschberg of ARMO, reported a vulnerability found in Kyverno 1.8.3 via the Kyverno security mailing list in which an unsigned image was permitted to run when a verifyImages rule existed which required only signed images. The vulnerability was introduced in Kyverno version 1.8.3.
To exploit this vulnerability, a malicious proxy or registry is used to replace the digest of a signed image with that of an unsigned image by exploiting a software bug that made a second call to the OCI registry using the mutable image tag. The attack requires that the attacker have the ability to inject a malicious proxy and requires that a workload references the proxy, or that the attacker takes control of a trusted OCI registry. The attack also requires that the admission controller does not have the ability to replace image tags with digests on first use and makes multiple calls using an image reference that uses a tag in a manner where different images can be sent by the malicious proxy or compromised registry back to the cluster.
The official advisory is available at: https://github.com/kyverno/kyverno/security/advisories/GHSA-m3cq-xcx9-3gvm.
Response and Fix
Prior to the December 14th disclosure, Ben had been in contact with the Kyverno team about another potential issue which was later disproved. While continuing testing, Ben uncovered this new vulnerability. The security team from Nirmata, the primary maintainers of Kyverno, engaged within hours of the initial report and worked over email and a private GitHub repository to investigate and validate the ultimate claim disclosed here. The root cause was quickly identified and a fix pushed to the upstream Kyverno repository within three days of verification. Kyverno 1.8.5 release candidate was released on Monday, December 19 2022 containing this fix and a GA release occurred two days later on Wednesday.
No Nirmata enterprise customers were known to be impacted and Nirmata has pulled versions 1.8.3 and 1.8.4 of its Nirmata Enterprise for Kyverno offering in the abundance of caution.
As we have advocated in prior posts, checking image signatures is a good starting point but not a complete solution to securing the software supply chain. Additional policies should be used to:
- Require that only trusted registries are used (sample policy).
- Ensure attestations (i.e. signed metadata) are checked for provenance and other image attributes (docs).
Requiring trusted registries would prevent this attack, as users cannot use the malicious proxy or other untrusted registries.
Securing Critical Software
Kubernetes admission controllers are critical components of any cluster and need to be battle tested to ensure they are reliable, resilient, and themselves secure. A community and OSS model allows wider use and enables multiple organizations to rapidly test, break, and fix issues in a collaborative manner. When choosing an admission controller, it is important to make sure that there is broad adoption, the admission controller has been designed and developed with security in mind, and thoroughly tested. Community based OSS models optimize these attributes and hence become the best choice for critical infrastructure.
Nirmata is the creator and primary maintainer of Kyverno. Nirmata provides Kubernetes policy and governance solutions built on Kyverno, including an enterprise version of Kyverno with long term support for CVEs and critical fixes.