A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can inject arbitrary key-value pairs into VM.platform, and the entire platform map is written to guest-visible xenstore at /local/domain/<domid>/platform/ during domain creation. The bulk write at domain.ml:486 dumps all platform keys - including attacker-injected keys alongside legitimate hypervisor configuration - into guest xenstore without filtering. Guest operating systems and guest agents that read the platform xenstore path treat all entries as trusted hypervisor configuration. There is no mechanism for the guest to distinguish legitimate keys from injected keys. The VM.platform field has zero map_keys_roles entries.
VM.platform is a Map(String, String) field defined at datamodel_vm.ml:2717-2720 with no ~map_keys_roles parameter. All keys are writable by vm-admin.
During domain creation, xenopsd writes the entire platform map to guest xenstore:
(* domain.ml:486 *)
xs.Xs.writev (dom_path ^ "/platform") vm_info.platformdata ;
This is a bulk write operation that dumps every key-value pair in the platform map into the guest xenstore path /local/domain/<domid>/platform/. Live xenstore examination confirms all platform keys are visible to the guest, including security-sensitive keys like featureset, nx, pae, and device_id.
The attack:
vm-admin injects arbitrary keys: VM.add_to_platform(vm, "custom-config-url", "https://evil.example.com/config")/local/domain/<domid>/platform/custom-config-urlThe guest has no cryptographic or structural mechanism to verify the provenance of platform keys. All entries under /local/domain/<domid>/platform/ are equally trusted.
Unfiltered bulk write. The entire platform map is dumped to guest xenstore without any key filtering. Both legitimate hypervisor configuration and arbitrary user-injected keys are written identically.
Missing RBAC protection. VM.platform has zero map_keys_roles entries. Unlike VM.other_config which restricts pci, folder, and XenCenter.CustomFields.*, the platform field has no per-key access control.
No guest-visible key whitelist. There is no allowlist defining which platform keys are intended to be guest-visible. All keys are exposed, including security-critical ones.
No write-time validation. Platform keys are validated only at VM start time via Vm_platform.sanity_check, not when they are written. The sanity_check is a key-name allowlist, not a value validator.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Arbitrary key injection to guest | Guest reads attacker-controlled values from platform xenstore | vm-admin, VM start | Confirmed (live xenstore dump) |
| Guest agent configuration hijack | Guest agent uses injected platform key for auto-configuration | vm-admin, guest agent reading platform keys | Modeled |
| Infrastructure metadata exposure | Legitimate platform keys (featureset, device_id) visible to guest | Default configuration | Confirmed (live xenstore dump) |
| BOC-1 chain | Pool-wide injection of arbitrary platform keys across all VMs | vm-admin, BOC-1 | Source-traced |
VM.platform writes for keys not in the standard platform key set/local/domain/*/platform/ for unexpected entriesdisclosure/vendor-detection-guidance.mdVM.platform records for unexpected keysFilter platformdata before xenstore write. Define a whitelist of keys intended to be guest-visible and filter the platform map before the bulk write at domain.ml:486. Do not dump the entire map to guest xenstore.
Add map_keys_roles to VM.platform. Restrict security-critical keys to _R_POOL_ADMIN. Allow vm-admin to set only cosmetic keys (e.g., timeoffset, vga).
Add write-time validation. Validate platform key values when they are set, not only when the VM starts.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
datamodel_vm.ml:2717-2720 (field definition, no map_keys_roles), domain.ml:486 (bulk write of entire platformdata to guest xenstore), vm_platform.ml:1-271 (sanity_check validates key names at start time, not values at write time), xapi_xenops.ml:1257-1264 (platformdata extraction with optional No_platform_filter bypass)disclosure/advisories/plat-security-advisory.md (PLAT-4)research/investigations/vm-platform.mdDiscovered and reported by Jakob Wolffhechel, Moksha.