Repository navigation
Security: Host-controlled Docker registry mirror enables image substitution attacks #616
Description
Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-wh3v-6w2w-vq9m by @pbeza.
Root Cause
The sys_config.docker_registry value is supplied by the host operator and injected into the Docker daemon configuration as registry-mirrors. This value is not measured in RTMR, not part of the compose hash, and not validated by the guest. The Docker daemon inside the CVM will preferentially pull images from the mirror before falling back to the canonical registry.
Attack Path
- Malicious host operator configures
sys_config.docker_registryto point to an attacker-controlled registry - CVM boots and configures Docker daemon with the malicious registry mirror
- When the CVM pulls container images (e.g., the MPC node image), Docker queries the mirror first
- Mirror serves a backdoored image with the same tag and manifest digest
- Backdoored container executes inside the CVM with access to keyshares and private keys
- Remote attestation does not detect the substitution because
docker_registryis not measured
Impact
A host operator can substitute any container image pulled inside the CVM. For MPC, this means the MPC node binary itself could be replaced with a backdoored version that exfiltrates keyshares, triples, and presignatures.
Suggested Fix
- Measure
docker_registryin RTMR3 as a runtime event - Enforce Docker Content Trust (DCT) / image signature verification inside the CVM
- Pin images by digest (SHA-256) in the compose configuration and verify after pull
- Alternatively, reject host-supplied registry mirrors entirely — embed trusted registries in the measured image
Note: This finding was reported automatically as part of an AI/Claude-driven internal audit by the NEAR One MPC team. It has not been manually verified by a human to confirm whether it constitutes an actual security issue.
Activity
kvinwang commentedon Mar 27, 2026
Maintainer response (copied from private security advisory GHSA-wh3v-6w2w-vq9m):
Thanks for the report, but this is not a security vulnerability.
The attack path described is not feasible when images are pinned by digest.
dstack's security model does not trust the registry — the registry is treated as an untrusted transport layer. Our security best practices require all images to use SHA256 digest pinning (e.g.,
image@sha256:eee5eae...). When Docker pulls an image by digest, it verifies the content hash after download. A malicious mirror cannot serve a different image with the same SHA256 digest — this would require a SHA256 collision.The compose configuration, including all image references with their digests, is hashed into the
compose-hashand measured in RTMR3. Remote attestation verifiers can confirm exactly which images are specified.Regarding the suggested fixes:
Measuring
docker_registryin RTMR3: Not appropriate. The registry is a transport/cache layer, not a trust boundary. Different mirrors should not produce different attestation measurements — this would unnecessarily restrict deployment flexibility.Docker Content Trust (DCT): Not suitable for decentralized scenarios. DCT requires a centralized Notary service and signing key management, which introduces a centralized trust dependency that contradicts dstack's design goals.
Pin images by digest: This is already a documented requirement in our security best practices.
Reject host-supplied mirrors: Overly restrictive with no security benefit — digest verification already guarantees image integrity regardless of the source.
That said, we recognize that relying on users to always remember digest pinning is not ideal. We plan to provide an automated auditing tool that checks compose configurations and warns if any image is referenced by mutable tag instead of SHA256 digest. This would help catch misconfigurations before deployment.