MOKSHA-2026-0078: Guest Clock Manipulation via VDI.other_config timeoffset

Summary

A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can manipulate the guest VM's RTC clock by setting the timeoffset key in VDI.other_config. When a VDI has on_boot=reset, the timeoffset value from VDI.other_config overrides the VM's platform-level timeoffset setting during domain creation (xapi_xenops.ml:312-327). Arbitrary strings are accepted - no type validation enforces the expected integer format. A corrupted timeoffset causes the guest OS to boot with an incorrect clock, affecting Windows license validation, certificate expiration checks, Kerberos authentication, scheduled task execution, and audit trail integrity. The VDI.other_config field has no map_keys_roles entries for infrastructure keys.

Vulnerability Description

VDI.other_config is a Map(String, String) field defined at datamodel.ml:6310-6315 with _R_VM_ADMIN as the minimum write role.

The timeoffset override logic at xapi_xenops.ml:312-327:

let rtc_timeoffset_of_vm ~__context ~vm =
  ...
  if vdi.API.vDI_on_boot = `reset then
    match
      (List.assoc_opt Vm_platform.timeoffset record.API.vDI_other_config)
    with
    | Some timeoffset -> timeoffset
    | None -> ...

When a VDI has on_boot=reset (common for snapshot-based VDIs), the timeoffset from VDI.other_config takes precedence over the VM platform setting. The value is expected to be an integer string representing the RTC offset in seconds from UTC, but no validation enforces this:

• Arbitrary strings (e.g., "not_a_number") are passed to the domain builder
• Extreme integer values (e.g., "999999999") shift the clock years into the future
• Negative extreme values shift the clock into the past

The attack requires the target VDI to have on_boot=reset set. This is common in environments using non-persistent VDIs or snapshot-based provisioning.

Root Causes

1. Missing type validation. The timeoffset value is expected to be an integer but any string is accepted without validation at write time.

2. Missing RBAC protection. VDI.other_config has map_keys_roles entries only for UI keys (folder, XenCenter.CustomFields.*). The timeoffset key is writable by any vm-admin.

3. VDI-level override of VM-level setting. The VDI.other_config timeoffset overrides the VM.platform timeoffset when on_boot=reset. This creates a secondary control path that bypasses any validation applied to the VM.platform field.

4. set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses map_keys_roles per-key checks.

Affected Systems

Directly Affected

• XenServer / Citrix Hypervisor - all versions (shared XAPI codebase)
• XCP-ng - all versions (confirmed via source trace)

Indirectly Affected

• Windows VMs - license validation, domain trust, and Kerberos authentication depend on accurate system time
• Certificate-dependent services - TLS certificates appear expired or not-yet-valid with corrupted clock
• Audit and compliance systems - log timestamps are incorrect, breaking audit trail integrity
• Scheduled tasks - cron jobs, Windows Task Scheduler entries execute at wrong times

Exploitation Scenarios

Chaining Analysis

• DOC-6 + DOC-7 (MOKSHA-2026-0051): Clock manipulation (DOC-6) combined with config drive misidentification (DOC-7) creates a compound guest misconfiguration - both the system clock and the cloud-init metadata are attacker-controlled.
• BOC-1 + DOC-6: Root access via BOC-1 enables bulk modification of timeoffset on every VDI with on_boot=reset, causing pool-wide guest clock corruption on next boot cycle.

Detection

• Monitor VDI.other_config writes for the timeoffset key
• Alert on timeoffset values that are non-integer or outside a reasonable range (e.g., -86400 to 86400 seconds)
• Monitor guest VM clock drift for anomalies
• See rule D-06 in disclosure/vendor-detection-guidance.md

Remediation

Short-Term Mitigations

• Audit all VDI.other_config entries for unexpected timeoffset values
• Monitor VDIs with on_boot=reset for timeoffset manipulation
• Use NTP within guest VMs to correct clock drift (mitigates but does not prevent initial boot with wrong time)

Long-Term Fix

Add write-time validation. Validate that timeoffset is a valid integer within a reasonable range (e.g., -86400 to 86400 seconds).

Add map_keys_roles protection. Restrict the timeoffset key to _R_POOL_ADMIN in datamodel.ml.

Upstream patches exist. They are held privately pending coordinated disclosure.

Disclosure

Disclosure:

• Public release: 2026-04-24 08:00 CEST
• CERT/CC notified: 2026-04-23
• MITRE CVE reservation filed: 2026-04-09 (no response as of publication)
• EU CVE registers notified: 2026-04-18 (GCVE/CIRCL, ENISA, DIVD - no response)
• Vendor (Cloud Software Group / Citrix): not contacted pre-publication
• Downstream maintainer (Vates/XCP-ng): contacted 2026-04-23 with conditional patch offer

References

• Related MOKSHA IDs: MOKSHA-2026-0006 (DOC-2), MOKSHA-2026-0019 (DOC-1), MOKSHA-2026-0020 (DOC-4), MOKSHA-2026-0034 (DOC-5), MOKSHA-2026-0051 (DOC-7)
• XAPI source: datamodel.ml:6310-6315 (VDI.other_config field definition), xapi_xenops.ml:312-327 (rtc_timeoffset_of_vm - VDI timeoffset override logic)
• Thematic advisory: disclosure/advisories/doc-security-advisory.md (DOC-6)
• Investigation: research/investigations/vdi-other-config.md

Credits

Discovered and reported by Jakob Wolffhechel, Moksha.