Skip to content

Runtime event log writable by any VM process #557

Closed

Description

@pbeza

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

  1. Attacker compromises a container inside the CVM
  2. Attacker appends forged events to /run/log/dstack/runtime_events.log
  3. The forged events cause RTMR3 replay to produce a different hash than the actual RTMR3 register
  4. This could cause legitimate attestation to fail (DoS against the CVM's attestability)
  5. Alternatively, if the attacker can truncate the log early, the replayed RTMR3 would be incomplete
  6. 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

  1. kvinwang commented on Mar 26, 2026

    @kvinwang
    Collaborator

    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.

  2. h4x3rotab commented on Jun 30, 2026

    @h4x3rotab
    Contributor

    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.

  3. added
    securitySecurity-related issue, report, or hardening work
    security: reportPublic security report or already-public security finding
    security: fixedSecurity report addressed by a code or configuration change
    on Jun 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    securitySecurity-related issue, report, or hardening worksecurity: fixedSecurity report addressed by a code or configuration changesecurity: reportPublic security report or already-public security finding

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions