The Kata agent policies generated by the Contrast CLI had an issue in the CopyFile verification, which allowed arbitrary writes to the guest root filesytem. A malicious process on the host with the capability to connect to the Kata agent VSOCK could connect to the agent and issue a series of CopyFile requests to overwrite security-critical files or trick the workload into disclosing sensitive data, which effectively amounts to a …
An attacker with control over the host (which is assumed in the attacker model of Contrast) can execute malicious AML code to gain arbitrary code execution within the confidential guest. AML is byte code embedded in ACPI tables that are passed from the host (QEMU) to the guest firmware (OVMF), and then passed from OVMF to the Linux kernel. The Linux kernel has an interpreter that executes the AML code. …
A malicious host may provide a crafted LUKS2 volume to a Contrast pod VM that uses the secure persistent volume feature. The guest will open the volume and write secret data using a volume key known to the attacker. LUKS2 volume metadata is (a) not authenticated and (b) supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume: Opens (cryptsetup open) without error using any …
This is the same vulnerability as https://github.com/edgelesssys/contrast/security/advisories/GHSA-h5f8-crrq-4pw8. The original vulnerability had been fixed for release v1.8.1, but the fix was not ported to the main branch and thus not present in releases v1.9.0 ff. Below is a brief repetition of the relevant sections from the first GHSA, where you can find the full details.
All of the following need to be true to be affected by this vulnerability: A bare metal Contrast deployment (AKS is not affected). An image with at least one VOLUME directive. No Kubernetes mount at the path of the VOLUME. If these are all true, the host is able to write arbitrary trees below that mount point.
When the Contrast initializer is configured with a CONTRAST_LOG_LEVEL of info or debug, the workload secret is logged to stderr and written to Kubernetes logs. Since info is the default setting, this affects all Contrast installations that don't customize their initializers' log level. The following audiences are intended to have access to workload secrets (see https://docs.edgeless.systems/contrast/1.7/architecture/secrets#workload-secrets): Contrast Coordinator (can derive all workload secrets) Contrast Initializer (obtains only the secret configured …
Recovering coordinators do not verify the seed provided by the recovering party. This allows an attacker to set up a coordinator with a manifest that passes validation, but with a secret seed controlled by the attacker. If network traffic is redirected from the legitimate coordinator to the attacker's coordinator, a workload owner is susceptible to impersonation if either they set a new manifest and don't compare the root CA cert …