Repository navigation
Security: Host-supplied sys_config not measured but influences security-critical behavior #615
Description
Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-m52x-2r7m-5p42 by @pbeza.
Root Cause
The CVM reads sys_config from the host at boot time. This configuration contains security-critical values that are NOT extended into any RTMR:
kms_urls: Which KMS instances the CVM contacts for key derivationgateway_urls: Which gateway instances the CVM registers withpccs_url: The Provisioning Certificate Caching Service URL used for DCAP quote verificationdocker_registry: Docker registry mirror (see F12010)host_api_url: The host API endpoint
None of these values are measured in RTMR3 or any other register. Remote attestation verifiers have no way to confirm that the CVM is communicating with the expected infrastructure.
Attack Path
- Malicious host operator sets
pccs_urlto an attacker-controlled PCCS - CVM boots and uses the attacker's PCCS for DCAP quote verification during KMS key provisioning
- Attacker's PCCS returns manipulated collateral (e.g., stale TCB info) to make invalid quotes pass
- KMS accepts the manipulated quote and provisions keys to an unattested CVM
- Alternatively: attacker redirects
kms_urlsto a rogue KMS that logs all derived keys
Impact
Host operator can redirect the CVM's connections to attacker-controlled infrastructure without detection by remote attestation. This undermines the entire trust model — the CVM believes it's communicating with legitimate KMS/gateway/PCCS but is actually talking to attacker infrastructure.
Suggested Fix
Extend all security-critical sys_config values into RTMR3 as runtime events:
emit_runtime_event("kms-urls", serde_json::to_string(&sys_config.kms_urls)?.as_bytes())?;
emit_runtime_event("gateway-urls", serde_json::to_string(&sys_config.gateway_urls)?.as_bytes())?;
emit_runtime_event("pccs-url", sys_config.pccs_url.as_bytes())?;MPC verifiers should then validate these events against expected values during attestation.
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-m52x-2r7m-5p42):
Thanks for the report, but this is not a security vulnerability.
dstack does not rely on these URLs or their domains as trust anchors. Security is enforced at the protocol level through cryptographic verification, not by trusting network endpoints. Specifically:
KMS (
kms_urls): Communication uses RA-TLS with mutual quote verification. Even if redirected to a rogue KMS, the RA-TLS handshake would fail because the rogue server cannot produce a valid TDX quote with the expected measurements. A rogue KMS cannot provision or intercept keys.Gateway (
gateway_urls): The gateway authenticates using TLS certificates issued by the KMS. A rogue gateway cannot present a valid KMS-signed certificate.PCCS (
pccs_url): The collateral returned by PCCS (TCB info, CRL, etc.) is signed by Intel. A malicious PCCS cannot forge Intel's signature. Stale or tampered collateral would fail signature verification.Docker registry (
docker_registry): As discussed in GHSA-wh3v-6w2w-vq9m, images are verified by SHA256 digest. A malicious registry cannot serve altered images.Host API (
host_api_url): Communication with the key provider uses mutual quote attestation and encrypted channels. A rogue endpoint cannot pass quote verification.Measuring these URLs in RTMR3 would add no security value — it would only reduce deployment flexibility by coupling attestation to specific infrastructure URLs. The correct trust model is to verify the identity of the remote party (via attestation and cryptographic signatures), not the address used to reach it.