Repository navigation
Description
The RTMR event log file managed by dstack/dstack-util/src/system_setup.rs is written to a world-readable path without integrity protection, so any process in the CVM can overwrite or truncate the log to hide evidence of measurements.
Root Cause
The runtime event log file (/run/log/dstack/runtime_events.log) is created without restrictive file permissions. Any process inside the CVM can write to this file, appending forged events or truncating existing entries. The event log is used for RTMR3 verification — verifiers replay the log to reconstruct the expected RTMR3 value.
Attack Path
- Attacker compromises a container inside the CVM
- Attacker appends forged events to
/run/log/dstack/runtime_events.log - The forged events cause RTMR3 replay to produce a different hash than the actual RTMR3 register
- This could cause legitimate attestation to fail (DoS against the CVM's attestability)
- Alternatively, if the attacker can truncate the log early, the replayed RTMR3 would be incomplete
- Note: the attacker cannot forge the actual RTMR3 hardware register (only the TDX module can extend it), so forged log entries would cause a mismatch, not a bypass
Impact
Denial of attestability — a compromised container can corrupt the event log so that RTMR3 replay verification fails, making the CVM appear untrustworthy even though the actual RTMR3 register is correct. The attacker cannot forge the hardware register itself, so this is primarily a DoS vector rather than an integrity bypass.
Suggested Fix
Set restrictive permissions on the event log file:
use std::os::unix::fs::OpenOptionsExt;
let file = std::fs::OpenOptions::new()
.create(true)
.append(true)
.mode(0o600) // Only root can read/write
.open("/run/log/dstack/runtime_events.log")?;Consider making the file append-only via chattr +a after creation.
Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.
Activity
kvinwang commentedon Mar 26, 2026
Thanks for the detailed report and for outlining a concrete hardening step.
Our current threat model treats the CVM as a single-tenant environment: we don't intend to run mutually untrusted workloads inside the same CVM. If an application wants to execute untrusted code, it should introduce its own sandboxing layer on top (e.g. separate CVMs/containers, language-level sandboxes, or other isolation mechanisms) rather than relying on the runtime event log for isolation between tenants.
That said, tightening the filesystem permissions on the runtime event log has no downside and does improve robustness against accidental or malicious tampering from other processes in the CVM. The log is now created with owner-only read/write permissions (0600) while keeping the existing location and format unchanged.
The change is implemented in #602.
h4x3rotab commentedon Jun 30, 2026
Maintainer triage update: this was fixed by #602 and is recorded in the public security report table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#public-reports-and-findings
Disposition: valid report, fixed. #602 restricts runtime event-log permissions.
Closing as fixed.