Kyverno CVE-2022-47633 affecting image verification
Updated Chip Zoller
CVE-2022-47633 is a high-severity (CVSS 8.1) flaw in Kyverno 1.8.3 and 1.8.4 that let a malicious proxy or registry swap a signed image for an unsigned one, bypassing verifyImages rules. Clusters on those versions that verify image signatures are affected. Upgrade to Kyverno 1.8.5, and allow only trusted registries as a mitigation.
CVE-2022-47633 at a glance
| Field | Detail |
|---|---|
| CVE | CVE-2022-47633 (GHSA-m3cq-xcx9-3gvm) |
| Component | Kyverno admission controller, verifyImages rules |
| Severity | High, CVSS 3.1 base score 8.1 |
| Affected | Kyverno 1.8.3 and 1.8.4 |
| Fixed | Kyverno 1.8.5 |
| Mitigation | A policy that restricts images to trusted registries |
For other Kyverno CVEs and their fixed versions, see the Kyverno security advisories page.
What was CVE-2022-47633?
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.
How did the attack work?
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. NVD lists it at nvd.nist.gov/vuln/detail/CVE-2022-47633.
How was it reported and fixed?
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 out of an abundance of caution.
How else can you mitigate it?
As we have advocated in prior posts, such as Kubernetes supply chain policy management with Cosign and Kyverno and a map for Kubernetes supply chain security, 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. The Kyverno advisory lists the same registry restriction as the workaround for clusters that cannot upgrade to 1.8.5 right away. For a wider view of the controls involved, see software supply chain security.
Why admission controller security matters
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.
About Nirmata
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.
You can start a free trial or evaluate Nirmata in the AWS Marketplace. You can contact Nirmata directly with any specific questions or observations you may have.
Frequently asked questions
Are Kyverno versions before 1.8.3 affected by CVE-2022-47633?
No. The GitHub advisory lists the vulnerable range as 1.8.3 to 1.8.4, and NVD lists only those two releases. The regression that made a second registry call by tag was introduced in 1.8.3. Version 1.8.5 is the first patched release, so anything on the 1.8.x line should be at 1.8.5 or later.
Does CVE-2022-47633 matter if I don't use verifyImages rules?
The advisory scopes the impact to users of Kyverno 1.8.3 or 1.8.4 who use verifyImages rules to check container image signatures and who do not block unknown registries. If your policies never verify signatures, the bypass has nothing to bypass. You should still upgrade, because 1.8.3 and 1.8.4 were pulled from Nirmata Enterprise for Kyverno.
Why is the CVSS attack complexity rated high?
NVD scores CVE-2022-47633 at 8.1 with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Attack complexity is high because the attacker has to sit between the cluster and the registry, through a malicious proxy that a workload references or a compromised trusted registry, and return a different digest on the second lookup of the tag.
Where can I track other Kyverno security advisories?
Kyverno publishes advisories on its GitHub security page at github.com/kyverno/kyverno/security/advisories, each with a GHSA ID, the affected and patched versions and any workaround. Nirmata also keeps a list of Kyverno advisories on nirmata.com. Subscribing to the Kyverno security mailing list is the fastest way to hear about new issues.