A vm-admin in XAPI-based hypervisors (XenServer, XCP-ng) can disable the VNC console for any PV (paravirtualized) guest by setting disable_pv_vnc in VM.other_config. The key is consumed at xapi_xenops.ml:497 via a presence check - when the key exists (any value), xenopsd sets vncterm=false and the VNC terminal is not started for the domain. In multi-tenant environments, a delegated vm-admin can deny console access to VMs under their management or, via the set_other_config bypass, to VMs managed by other administrators. The key takes effect on the next VM boot without requiring operator intervention.
VM.other_config is a Map(String, String) field writable by vm-admin. The disable_pv_vnc key controls whether the VNC terminal (vncterm) is started for PV guest domains.
The code path:
vm-admin sets the key: VM.add_to_other_config(vm, "disable_pv_vnc", "true")xapi_xenops.ml:497:vncterm= not (List.mem_assoc "disable_pv_vnc" vm.API.vM_other_config)
vncterm is set to falseThe check is a simple presence check using List.mem_assoc. Any value (including empty string) triggers the behavior. No validation, no RBAC check, and no security logging occurs.
Missing RBAC protection. VM.other_config has map_keys_roles entries for pci, folder, and XenCenter.CustomFields.* only. The disable_pv_vnc key is writable by vm-admin without restriction.
Presence-only check. The consumption code uses List.mem_assoc (presence check) rather than value validation. Any value - including empty string, "false", or garbage - disables the VNC terminal.
No operational logging. Disabling the VNC console produces no security-level log entry. Operators discover the disabled console only when they attempt to connect.
set_other_config RBAC bypass. The set_other_config method replaces the entire map and bypasses per-key RBAC, enabling cross-tenant console manipulation.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Console denial | Disable VNC console for target PV VM, preventing operator access | vm-admin, PV guest | Source-traced |
| Multi-tenant disruption | In delegated environments, disable console for VMs managed by other admins (via set_other_config) | vm-admin | Source-traced |
| Cover for other attacks | Disable console before performing other attacks, preventing operator observation | vm-admin | Modeled |
| BOC-1 chain | vm-admin uses BOC-1 S3 to bulk-disable consoles across all PV VMs | vm-admin, BOC-1 | Source-traced |
disable_pv_vnc on all PV VMs, disabling console access pool-wide. This compounds with other attacks by preventing operators from observing or debugging compromised VMs.is_system_domain privilege escalation (VOC-1) creates a scenario where the attacker escalates privileges and simultaneously prevents console-based incident response.VM.other_config for writes to the disable_pv_vnc keydisable_pv_vnc entries, especially on production VMsother_config changesdisclosure/vendor-detection-guidance.mdVM.other_config records for unexpected disable_pv_vnc entriesdisable_pv_vnc keys that were not set by a pool administratorother_config changesAdd map_keys_roles protection. Restrict disable_pv_vnc to _R_POOL_ADMIN in the VM field definition in datamodel.ml.
Add security logging. Log a security-level event when disable_pv_vnc is set or removed, including the session and role of the caller.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_xenops.ml:497,518 (disable_pv_vnc presence check), datamodel.ml (VM.other_config field definition, map_keys_roles does not include disable_pv_vnc)disclosure/advisories/voc-security-advisory.md (VOC-6)research/investigations/vm-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.