Contrast vulnerabilities

In Contrast versions before 1.18.0, the guest kernel's ACPI/AML handling is vulnerable to an AML injection attack ("BadAML"). A malicious host can supply an ACPI table with arbitrary AML bytecode that the guest kernel interpreter executes with access to all guest memory, including private pages. This affects AMD SEV-SNP platforms (Metal-QEMU-SNP and Metal-QEMU-SNP-GPU); Metal-QEMU-TDX is not affected.

In Contrast versions before 1.19.1, Kata agent policies generated by the Contrast CLI contained a flaw in CopyFile verification that allowed arbitrary writes to the guest root filesystem. A malicious process on the untrusted host able to connect to the Kata agent VSOCK could overwrite security-critical files or trick the workload into disclosing sensitive data, effectively amounting to a full guest takeover.

Contrast (Edgeless Systems) through 1.20.0 performs unanchored suffix matching when selecting per-registry configuration in the imagepuller. Config.registryFor strips a single trailing dot and then uses strings.HasSuffix(hostname, fqdn) without requiring a DNS label boundary, so a registry entry such as [registries."ghcr.io."] is also applied to any host whose name merely ends in that byte sequence, including attacker-registered domains such as evilghcr.io. When an image or layer is pulled from such a sibling domain, the imagepuller sends the configured Authorization header (basic auth, registry token, or identity token), trusts the configured custom CA bundle, follows the configured mirror, and honours insecure-skip-verify (disabling TLS verification) for that host.

Contrast through 1.20.0 contains a panic vulnerability in the transit-engine endpoint's ciphertextContainer.UnmarshalJSON function that fails to validate decoded ciphertext length before slicing. An authenticated workload with a valid mesh certificate can trigger a runtime panic by submitting a short base64-encoded ciphertext, causing log spam and request failures without crashing the process.

Contrast before 1.16.0 is susceptible to remote attestation relay attacks. Contrast accepted any correctly verified TEE attestation report with the expected firmware patch levels and software measurements, regardless of which machine produced it, so attestation was not bound to specific, physically trusted hardware. An attacker able to intercept network traffic and forge reports can impersonate a Contrast Coordinator or workload, defeating identity verification in aTLS.

Contrast (edgelesssys/contrast) versions 1.14.0 before 1.23.1 generate runtime policies that fail to detect all container image substitutions. A bad rebase during a Kata Containers update introduced an 'allow_storage' rule that accepts storage entries using the 'image_guest_pull' driver without verifying the image digest. An attacker with access to the Kata agent API can substitute a container image with an exploit payload if it satisfies the remaining policy rules.

Contrast versions before 1.4.1 — a recovering Coordinator does not verify the seed supplied by the recovering party. An attacker can stand up a rogue Coordinator whose manifest passes validation but whose secret seed is attacker-controlled. If network traffic is redirected from the legitimate Coordinator to the attacker's Coordinator, a workload owner can be impersonated when they set a new manifest without comparing the returned root CA certificate against the existing one or verify the Coordinator without comparing the root CA certificate against a trusted reference.

Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider.

Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality.

Edgelesssys Contrast is a confidential-computing runtime for Kubernetes. In versions 1.9.0 before 1.12.2, the initializer logs the full NewMeshCert response — which contains the workload secret — to standard output at INFO level. As a result, workload secrets are exposed to any Kubernetes user with get or list permission on pods/logs. Because workload secrets are used for encrypted storage and Vault integration, those must also be considered compromised.

Contrast, a Kubernetes runtime for confidential containers, before version 1.12.1 has a vulnerability in the secure persistent volume feature. A malicious host can supply a crafted LUKS2 volume to a pod VM. LUKS2 volume metadata is not authenticated and, with cryptsetup versions prior to 2.8.1, a header specifying the null keyslot encryption algorithm (cipher_null-ecb) is accepted without error. Because the Contrast Initializer assumes a device is protected if `cryptsetup open` succeeds with the secret seed, the guest will open the attacker-supplied volume and write secret data in plaintext, or under a volume key known to the attacker, allowing the host to read confidential data that should have been encrypted.