A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can poison VDI.xenstore_data before a snapshot or clone operation, causing malicious data to propagate to all descendant VDI records. The snapshot and clone code at xapi_vdi.ml:861-862 copies the parent VDI's xenstore_data to the new VDI record without re-validation. A single injection fans out through the entire snapshot/clone hierarchy - every descendant VDI inherits the poisoned metadata. The field has zero map_keys_roles restrictions and zero write-time validation.
VDI snapshot and clone operations create new VDI records that inherit metadata from the parent. The code path at xapi_vdi.ml:861-862 explicitly copies xenstore_data:
Db.VDI.set_xenstore_data ~__context ~self:newvdi
~value:vdi_rec.API.vDI_xenstore_data ;
This is the intended behavior for SM-generated metadata - SCSI identity and storage type data should propagate to snapshots. The problem is that attacker-injected data is indistinguishable from SM-generated data and propagates identically.
The attack sequence:
vm-admin injects poisoned data: VDI.add_to_xenstore_data(vdi, "storage-type", "attacker-controlled")vm-admin (or an automated process) triggers a snapshot or clonexapi_vdi.ml:861-862 copies xenstore_data including the poisoned entry to the new VDIThe propagation is permanent. Even if the original poisoned entry is removed from the parent VDI, all existing descendants retain their copy. There is no mechanism to cascade a cleanup through the snapshot tree.
Unconditional metadata copy. Snapshot and clone operations copy xenstore_data without filtering, validation, or re-generation from the SM driver.
No provenance distinction. The copy operation cannot distinguish SM-generated entries from user-injected entries. Both propagate identically.
Missing write-time validation. The parent VDI accepts any key-value pair without validation, ensuring the poisoned data exists to be copied.
No cleanup cascade. Removing a key from a parent VDI does not propagate the removal to existing descendants.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Snapshot tree poisoning | All descendants inherit injected metadata | vm-admin, snapshot trigger | Source-traced |
| Template poisoning | VMs provisioned from template inherit poisoned VDI metadata | vm-admin, template with snapshots | Source-traced |
| Fan-out amplification | Single injection multiplied across every snapshot/clone descendant | vm-admin, active snapshot schedule | Source-traced |
| Persistent contamination | Removing injection from parent does not clean descendants | vm-admin, existing snapshot tree | Source-traced |
VDI.xenstore_data between parent and child VDIs for unexpected inherited entriesxenstore_data entries that are identical across an entire snapshot tree but do not match SM driver outputxenstore_data writes followed by snapshot/clone operationsdisclosure/vendor-detection-guidance.mdVDI.xenstore_data in snapshot trees for unexpected entriesxenstore_data against SM driver outputxenstore_dataRe-generate xenstore_data on snapshot/clone. Instead of copying the parent's database field, query the SM driver for fresh metadata during snapshot/clone. This eliminates propagation of user-injected data.
Add validation on copy. If direct SM query is not feasible, validate the copied xenstore_data against a whitelist of SM-known keys before storing in the new VDI record.
Restrict write access. Change the field write role to _R_POOL_ADMIN to prevent vm-admin from poisoning the source data.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_vdi.ml:861-862 (snapshot/clone copies xenstore_data to new VDI), datamodel.ml:6352-6369 (field definition, no map_keys_roles), xapi_vdi.ml:681 (VDI.create), xapi_vdi.ml:792 (VDI.introduce)disclosure/advisories/vxd-security-advisory.md (VXD-3)research/investigations/vdi-xenstore-data.mdDiscovered and reported by Jakob Wolffhechel, Moksha.