A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can inject arbitrary key-value pairs into a guest domain's xenstore vm-data/ directory by writing to VM.xenstore_data. The guest OS and guest agents read this directory as trusted hypervisor configuration. There is no mechanism for the guest to distinguish legitimate hypervisor-provided data from attacker-injected data. Guest agents that consume xenstore configuration - server endpoints, update sources, monitoring targets - are directed to attacker-controlled infrastructure. The field has zero per-key RBAC protection, and the only filtering is a weak prefix check in xenopsd that permits all keys starting with vm-data/.
VM.xenstore_data is a Map(String, String) field writable by vm-admin. Values are written directly into the guest domain's xenstore at /local/domain/<domid>/vm-data/. The vm-data directory is created with read-write permissions (rwperm) for the guest domain.
The code path:
vm-admin calls VM.add_to_xenstore_data(vm, "vm-data/config-endpoint", "https://attacker.example.com")message_forwarding.ml:2092-2099)xapi_xenops.ml:1355)domain.ml:164-170) - only vm-data/ and FIST/ prefixes are allowed/local/domain/<domid>/vm-data/ with rwperm (domain.ml:604-624)The prefix filter is the only security control in the entire chain. It performs no value validation, no key depth restriction, and no length limits.
Missing RBAC protection. VM.xenstore_data has zero map_keys_roles entries in datamodel_vm.ml. Every key is writable by vm-admin via add_to_xenstore_data or set_xenstore_data.
Missing value validation. No validation occurs at any stage - XAPI, xenopsd, or xenstore. Arbitrary binary data is accepted as values.
Trust boundary violation. Guest agents treat vm-data/ as a trusted hypervisor configuration channel. There is no authentication or integrity verification on xenstore entries.
set_xenstore_data bypass. The set_xenstore_data method replaces the entire map atomically, bypassing any future per-key checks.
vm-data/ for configuration| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Server endpoint redirection | Guest agent connects to attacker-controlled server for updates, telemetry, or configuration | vm-admin, guest running PV agents | Source-traced |
| Configuration injection | Guest behavior modified via injected configuration keys (network settings, service endpoints) | vm-admin, guest agents consuming vm-data | Source-traced |
| Update source poisoning | Guest agent downloads updates from attacker-controlled source | vm-admin, guest agent with update functionality | Modeled |
| Multi-tenant trust confusion | In delegated environments, vm-admin modifies guest configuration across trust boundaries | vm-admin, multi-tenant deployment with delegated VM management | Modeled |
VM.xenstore_data writes via XAPI event stream for unexpected keysvm-data/ xenstore paths inside guest domains for keys not set by the hypervisor administratorVM.set_xenstore_data calls that replace the entire map (potential bulk injection)disclosure/vendor-detection-guidance.mdNo reliable guest-side detection exists. The guest cannot distinguish injected data from legitimate hypervisor configuration.
VM.xenstore_data records for unexpected keysAdd map_keys_roles. Protect infrastructure-critical vm-data/ key prefixes in datamodel_vm.ml at _R_POOL_ADMIN to prevent vm-admin from injecting guest configuration.
Guest-side integrity verification. Guest agents should not blindly trust xenstore data. Implement signature verification or out-of-band validation for configuration consumed from vm-data/.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
datamodel_vm.ml:2818-2831 (field definition), message_forwarding.ml:2092-2099 (write path), xapi_xenops.ml:1355 (xenopsd passthrough), domain.ml:164-170 (prefix filter), domain.ml:604-624 (xenstore write with rwperm)disclosure/advisories/xsd-security-advisory.md (XSD-1)research/investigations/vm-xenstore-data.mdDiscovered and reported by Jakob Wolffhechel, Moksha.