Security Policy⚓︎
Supported versions⚓︎
While all known vulnerabilities in the Connaisseur application are listed below and we intent to fix vulnerabilities as soon as we become aware, both, Go and OS packages of the Connaisseur image may become vulnerable over time and we suggest to frequently update to the latest version of Connaisseur or rebuilding the image from source yourself. At present, we only support the latest version. We stick to semantic versioning, so unless the major version changes, updating Conaisseur should never break your installation.
Known vulnerabilities⚓︎
| Title | Affected versions | Fixed version | Description |
|---|---|---|---|
| initContainers not validated | ≤ 1.3.0 | 1.3.1 | Prior to version 1.3.1 Connaisseur did not validate initContainers which allowed deploying unverified images to the cluster. |
| Ephemeral containers not validated | ≤ 3.1.1 | 3.2.0 | Prior to version 3.2.0 Connaisseur did not validate ephemeral containers (introduced in k8s 1.25) which allowed deploying unverified images to the cluster. |
| Regex Denial of Service for Notary delegations | ≤ 3.3.0 | 3.3.1 | Prior to version 3.3.1 Connaisseur did input validation on the names of delegations in an unsafe manner: An adversary with the ability to alter Notary responses, in particular an evil Notary server, could have provided Connaisseur with an invalid delegation name that would lead to catastrophic backtracking during a regex matching. Only users of type notaryv1 validators are affected as Connaisseur will only perform this kind of input validation in the context of a Notary validation. If you mistrust the Docker Notary server, the default configuration is vulnerable as it contains a notaryv1 validator with the root keys of both Connaisseur and the library of official Docker images. |
| Cosign multi-signature threshold bypass | ≤ 3.11.0 | 3.11.1 | Prior to version 3.11.1, Cosign validators using trustRoot: "*" with an explicit threshold or implicit require-all policy counted valid signature layers instead of distinct validating trust roots. An attacker controlling one configured signing key could attach multiple signatures and satisfy the threshold without the intended signer quorum, allowing an image to be admitted without signatures from the other required trust roots. |
| Notary v1 delegation silent fallback on fetch failure | ≤ 3.11.0 | 3.11.1 | Prior to version 3.11.1 Connaisseur could silently fall back to the canonical targets trust role when downloading a delegation role failed with an "error acquiring trust data" message and the snapshot metadata contained no hash entry for the requested delegation. This fallback was intended for the edge case where delegation signers are registered but have never signed anything. However, the guard condition did not distinguish between implicitly resolved delegations and delegations explicitly required by the operator. An adversary with control over the Notary server and the targets signing key could therefore bypass an explicitly configured delegation requirement by causing the delegation fetch to fail and serving an image signed only at the targets level. Note that an adversary already holding the targets key could also remap delegation key assignments directly in targets.json; this fallback provided a stealthier path to the same outcome without requiring a detectable metadata change. Only users of type notaryv1 validators with explicit delegations configured in their policy rules are affected. |
| Notary reference registry confusion | ≤ 3.11.1 | 3.12.0 | Prior to version 3.12.0 Connaisseur's Notary (v1) validator would normalize the Notary registry of validated images if they started with DockerHub's default index.docker.io. This check did not ensure that index.docker.io was the actual host and thus would normalize paths for other registry hosts as well. As a consequence, the validated image reference could be faulty (on the correct Notary server). An attacker with access to the Notary server could then have served old (frozen or downgraded) images signed with the correct keys. |
| Ignored Notary path constraints | ≤ 3.11.1 | 3.12.0 | Prior to version 3.12.0 Connaisseur's Notary (v1) validator did not respect path constraints. Notary allows scoping delegations to paths. Connaisseur would not validate that the target signed by a valid delegation of the repository was acutally in scope of the delegation. |
| Credential leak | ≤ 3.11.1 | 3.12.0 | Prior to version 3.12.0 Connaisseur would match the registry credentials to a container registry without being host-aware. This way, an attacker could trick Connaisseur into sending the credentials for the container registry to an attacker-controlled host. |
Reporting a vulnerability⚓︎
We are very grateful for reports on vulnerabilities discovered in the project, specifically as it is intended to increase security for the community. We aim to investigate and fix these as soon as possible. Please submit vulnerabilities to connaisseur@securesystems.dev.