Advisories for Golang/Github.com/Edgelesssys/Contrast package

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 …