A vm-admin can manipulate the owner key in VBD.other_config to cause unintended VDI deletion or prevent VDI cleanup during VM uninstall operations. The owner key is read by cli_operations.ml:4315-4318 during xe vm-uninstall to determine whether a VDI should be destroyed with its parent VM. By setting owner="" on a shared VDI's VBD, an attacker causes the uninstall operation to destroy a VDI that is still in use by other VMs - data destruction. By removing the owner key from a non-shared VBD, the attacker causes VDIs to be orphaned on uninstall - storage leak that accumulates over time. The key has no per-key RBAC protection.
VBD.other_config is a Map(String, String) field writable by vm-admin. The owner key participates in VDI lifecycle management.
XAPI sets the owner key automatically:
xapi_vbd.ml:264 sets owner=true on the VBDxapi_vm_clone.ml:488-490 sets owner="" on cloned VBDsThe key is consumed during VM uninstall:
cli_operations.ml:4315-4318 checks for the presence of the owner keyowner is present (any value, including empty string), the associated VDI is marked for destructionowner is absent, the VDI is skippedScenario A - Data destruction via shared VDI:
X is attached to VM-A (owner=true) and VM-B (no owner key)owner="" on VM-B's VBD to VDI Xxe vm-uninstall sees owner present and destroys VDI XScenario B - Storage leak:
owner key from a VBDMissing RBAC protection. VBD.other_config has zero map_keys_roles entries for the owner key. Any vm-admin can modify it.
Presence-based check. The consumption logic checks for key presence, not key value. An empty string owner="" triggers the same behavior as owner=true.
No provenance verification. The consumer (cli_operations.ml) does not verify whether the owner key was set by a trusted internal XAPI operation or injected by an external API caller.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Shared VDI destruction | Data loss when VM is uninstalled - shared VDI destroyed | vm-admin, shared VDI with multiple VBDs | Source-traced |
| Storage leak | Orphaned VDIs accumulate, causing gradual storage exhaustion | vm-admin, repeated VM lifecycle | Source-traced |
| Targeted data destruction | Destroy a specific VDI by manipulating its VBD owner key | vm-admin, knowledge of VDI-VBD relationship | Modeled |
VBD.other_config writes for the owner key from API usersowner key changes on VBDs attached to shared VDIsdisclosure/vendor-detection-guidance.mdVBD.other_config records for unexpected owner key valuesValidation at consumption point. cli_operations.ml:4315-4318 should verify that the owner key was set by a trusted internal XAPI operation (VBD creation, VM clone) rather than accepting any value. This requires a provenance mechanism to distinguish internal writes from external API writes.
Note: The owner key is intentionally excluded from simple map_keys_roles protection because XAPI sets it automatically during VBD creation and VM clone. Restricting it via map_keys_roles would break these internal flows. The fix requires consumer-side validation rather than write-time RBAC.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
cli_operations.ml:4315-4318 (owner key consumption), xapi_vbd.ml:264 (owner key set on VBD creation), xapi_vm_clone.ml:488-490 (owner key set on clone), datamodel.ml (VBD field definition)disclosure/advisories/boc-1-security-advisory.md (BOC-4 / V3)research/investigations/vbd-other-config.mdresearch/boc-1/poc/boc-1-v3-owner-lifecycle.shDiscovered and reported by Jakob Wolffhechel, Moksha.