Zero `mr_config_id` bypasses verification + weakens `mr_aggregated` identity

[pbeza]

The attestation verification in dstack/kms/src/main_service.rs treats an all-zero mr_config_id in the quote as a wildcard, skipping the config identity check. An attacker who can produce a quote with a zeroed mr_config_id would bypass this verification.

Root Cause

When mr_config_id is all zeros, two things happen:

1. The config ID verifier skips verification entirely (config_id_verifier.rs:40-42): if mr_config_id == [0u8; 48], verification returns Ok(()) without checking any configuration.

2. The mr_aggregated computation excludes mr_config_id when it's zero (attestation.rs:407-428): different configurations produce the same mr_aggregated hash because the config measurement is omitted rather than included as zeros.

Attack Path

1. Host operator launches a CVM without setting mr_config_id (defaults to all zeros)
2. Config ID verification is skipped — no configuration integrity check occurs
3. The mr_aggregated identity hash does not include any configuration measurement
4. A CVM with malicious configuration produces the same mr_aggregated as one with legitimate configuration
5. Remote verifiers checking mr_aggregated cannot distinguish between the two

Impact

Configuration integrity verification can be trivially bypassed by not setting mr_config_id. The mr_aggregated identity becomes weaker because it doesn't include configuration state. Different CVM configurations appear identical to remote verifiers.

Suggested Fix

1. Treat zero mr_config_id as a verification failure rather than a skip condition
2. Always include mr_config_id in mr_aggregated computation, even when zero:

// Always include in aggregated hash
hasher.update(&mr_config_id);

// Reject zero config_id in production
if mr_config_id == [0u8; 48] {
    return Err(Error::MissingConfigId);
}

---

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.