GHSA-vqv5-385r-2hf8 Contrast's unauthenticated recovery allows Coordinator impersonation

• Go github.com/edgelesssys/contrast: < 1.4.1 → fixed in 1.4.1

Impact 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 with the existing one (this is the default of the `contrast` CLI) or • they `verify` the coordinator and don't compare the root CA cert with a trusted reference. Under these circumstances, the attacker can: • Issue certificates that chain back to the attacker coordinator's root CA. • Recover arbitrary workload secrets of workloads deployed after the attack. This issue does not affect the following: • secrets of the legitimate coordinator (seed, workload secrets, CA) • integrity of workloads, even when used with the rogue coordinator • certificates chaining back to the mesh CA Patches This issue is patched in Contrast v1.4.1. Workarounds The issue can be avoided by verifying the coordinator root CA cert against expectations. • At the first `set` call, keep a copy of the CA cert returned by the coordinator. • After subsequent `set` or `verify` calls, compare the returned CA cert with the backup copy. If it matches bit-for-bit, the coordinator is legitimate.