Summary
Contrast versions 1.14.0 through before 1.23.1 can generate runtime policies that accept certain container image substitutions without verifying the image digest. An attacker with access to the Kata agent API may replace an image with a malicious one that satisfies the remaining policy requirements, weakening confidential-container integrity protections.
Affected context
The issue occurs in Contrast deployments using runtime policies for Kata Containers when an
allow_storage rule permits entries associated with the image_guest_pull driver without
binding the accepted image to an expected digest. Exploitation depends on access to the Kata
agent API and on the replacement image satisfying other applicable policy conditions.
Exploit preconditions
- Attack surface: The Kata agent API and runtime policy enforcement path
- Required access: Access sufficient to request or influence container image handling through the agent API; in the stated threat model, this may include Kubernetes cluster administrator access
- Trigger point: A container image substitution evaluated against a generated runtime policy
- Why exploitation is possible: The relevant storage rule accepts an image-pull mechanism without consistently validating the image digest, allowing an alternative image to pass when other policy rules are satisfied
Why this happens
The root cause is incomplete validation of security-relevant image metadata in generated runtime
policies. A storage rule permits the image_guest_pull driver without requiring the resolved
image to match an approved digest, so policy evaluation validates only part of the expected
image identity. This maps to CWE-20: Improper Input Validation, because an input that
controls trusted container content is accepted without enforcing all required integrity
constraints.
Potential impact
- A malicious container image may be substituted for an approved image
- Confidential-container integrity guarantees could be weakened
- Unauthorized code may execute inside a protected workload
- Sensitive data or workload operations could be exposed to tampered code
- Trust in image-based supply-chain controls may be undermined
General mitigation guidance
Mitigation generally focuses on making image identity validation complete and fail closed.
Common defensive patterns include:
- Require every accepted image source and storage driver to be bound to an allowlisted, immutable digest
- Reject image references when digest resolution or comparison is unavailable
- Generate policies from a single authoritative image identity rather than independently trusted fields
- Apply equivalent validation to all image acquisition paths, including guest-side pulls
- Restrict access to the Kata agent API using least privilege and strong administrative boundaries
- Continuously verify that running workloads correspond to approved image digests
How teams detect issues like this
Detection approaches can include:
- Static analysis for policy branches that authorize image sources without digest comparison
- Code review of generated
allow_storagerules and all alternate image-pull drivers - Tests that attempt policy evaluation with the same image name but a different digest
- Runtime monitoring for image pulls or storage entries whose resolved digest differs from the approved identity
- Policy-as-code checks requiring immutable image references and explicit failure on missing metadata
- Automated security review tools that flag incomplete validation of security-sensitive container inputs
