The VM.xenstore_data field in XAPI-based hypervisors (XenServer, XCP-ng) creates a bidirectional data channel between guest domains and the XAPI management database. Guest writes to vm-data/ in xenstore are read by xenopsd during periodic state synchronization (xenops_server_xen.ml:3246-3248) and propagated into VM.xenstore_data in the XAPI database (xapi_xenops.ml:2431-2441). This is the only confirmed path where a guest domain can inject data into the XAPI database without any API authentication. Live-tested: guest-written data appears in the XAPI DB within 5 seconds. Any API consumer reading VM.xenstore_data receives attacker-injected values.
The vm-data/ directory in xenstore is created with rwperm (read-write permissions for the guest domain) at domain.ml:604-624. This means the guest domain can write arbitrary keys and values under /local/domain/<domid>/vm-data/.
The reverse sync path:
/local/domain/<domid>/vm-data/injected-key via xenstore-writevm-data/ from xenstore (xenops_server_xen.ml:3246-3248)VM.set_xenstore_data internal call (xapi_xenops.ml:2431-2441)VM.xenstore_data in the databaseVM.xenstore_data receives the guest-injected valuesNo authentication or integrity check occurs on the reverse path. The XAPI database trusts data originating from the guest domain.
Bidirectional xenstore permissions. The vm-data/ directory is created with rwperm instead of roperm, allowing the guest to write back into a host-synced namespace.
Unvalidated reverse sync. xenopsd's event loop propagates guest-written data into the XAPI database without any validation, sanitization, or origin marking.
No origin tracking. The XAPI database does not distinguish between data written by an API user (vm-admin) and data written by the guest domain. Both appear identically in VM.xenstore_data.
Trust assumption by API consumers. Any system reading VM.xenstore_data assumes the data was set by a trusted API user. Guest-injected data breaks this assumption.
VM.xenstore_data without origin verificationVM.xenstore_data via the API| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| XAPI DB injection from guest | Guest domain writes arbitrary data into the host management database | Running VM with PV drivers or xenstore access | Confirmed (live-tested) |
| Orchestrator poisoning | Injected data consumed by management tools that trust XAPI metadata | Guest domain, orchestrator reading xenstore_data | Modeled |
| Cross-domain data exfiltration | Guest uses vm-data writeback to signal data to a colluding API consumer | Guest domain, colluding vm-admin or pool-operator | Source-traced |
| Metadata integrity corruption | Guest-written values corrupt metadata relied upon by backup and monitoring systems | Running VM, systems consuming VM.xenstore_data | Modeled |
VM.xenstore_data for changes that do not correlate with API calls (indicates guest-side writes propagated via xenopsd sync)VM.xenstore_data from xenopsd event syncVM.xenstore_data contents against known-good baselinesdisclosure/vendor-detection-guidance.mdVM.xenstore_data for unexpected keys not set by administratorsVM.xenstore_data values in automation or monitoring without independent validationvm-data/Change vm-data permissions. Replace rwperm with roperm in domain.ml:604-624 to break the bidirectional sync. The guest should not be able to write to vm-data/ - this directory is a host-to-guest configuration channel, not a bidirectional communication bus.
Add origin tracking. If bidirectional sync is an intentional feature, mark guest-originated data with an origin flag so API consumers can distinguish it from administrator-set values.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
domain.ml:604-624 (rwperm on vm-data), xenops_server_xen.ml:3246-3248 (reverse sync read), xapi_xenops.ml:2431-2441 (XAPI DB write from xenopsd)disclosure/advisories/xsd-security-advisory.md (XSD-3)research/investigations/vm-xenstore-data.mdDiscovered and reported by Jakob Wolffhechel, Moksha.