A pool-operator can redirect all VIF traffic on a network through an attacker-controlled VM by setting Network.other_config:backend_vm to a VM UUID they control. XAPI reads this key in xapi_xenops.ml:155-161 and returns Network.Remote(backend_vm, bridge) instead of Network.Local(bridge) for all subsequent VIF creations on that network. All VMs subsequently connected to the network have their traffic routed through the attacker VM, enabling traffic interception, credential sniffing, and man-in-the-middle attacks. The key has no map_keys_roles protection and no write-time validation.
Network.other_config is a Map(String, String) field writable by pool-operator with zero map_keys_roles entries protecting infrastructure keys. The backend_vm key controls which VM serves as the backend for VIFs on the network.
pool-operator calls Network.add_to_other_config(net, "backend_vm", "<attacker-vm-uuid>")
-> xapi_xenops.ml:155-161 reads backend_vm from Network.other_config
-> Returns Network.Remote(backend_vm, bridge) instead of Network.Local(bridge)
-> All new VIFs on this network route through the attacker VM
-> Attacker VM sees all packets: can log, modify, or drop traffic
When a VIF is created or plugged, xapi_xenops.ml checks for the backend_vm key in the network's other_config. If present, the VIF is configured to route through the specified VM rather than the local bridge. No validation confirms that the target VM is a legitimate driver domain or network service.
Missing RBAC protection. Network.other_config has zero map_keys_roles entries for infrastructure keys. The backend_vm key is writable by pool-operator via add_to_other_config.
Missing consumer-side validation. xapi_xenops.ml reads backend_vm and uses it as a VIF backend with no check that the referenced VM is authorized to serve as a network backend (e.g., a driver domain).
set_other_config RBAC bypass. The set_other_config method replaces the entire map atomically and bypasses any map_keys_roles per-key checks.
Insufficient logging. No security-level alert is generated when a network backend is redirected to a non-driver-domain VM.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| Traffic interception | All VIF traffic on the network visible to attacker VM | Attacker VM on same network | Modeled (code-traced) |
| Credential sniffing | Capture authentication traffic from co-hosted VMs | Unencrypted protocols in use | Modeled (follows from traffic interception) |
| Man-in-the-middle | Modify traffic in transit between VMs | Attacker VM configured as transparent bridge | Modeled |
| BOC-1 chain | vm-admin escalates to pool-operator via BOC-1 S3, then hijacks VIF backend | BOC-1 available | Modeled (two-step chain) |
Network.other_config for writes to the backend_vm keybackend_vm value that references a non-driver-domain VMbackend_vm entriesdisclosure/vendor-detection-guidance.mdNetwork.other_config records for unexpected backend_vm keyspool-operator role grants to trusted administratorsNetwork.add_to_other_config callsRBAC restriction. Add map_keys_roles entries to Network.other_config in datamodel.ml. The backend_vm key requires _R_POOL_ADMIN or higher. Alternatively, restrict to validated driver domain UUIDs only.
Consumer-side validation. Validate in xapi_xenops.ml that the backend_vm UUID references a VM with is_control_domain=true or an explicit driver domain flag before accepting it as a VIF backend.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
xapi_xenops.ml:155-161 (backend_vm read), datamodel.ml (Network field definition)disclosure/advisories/noc-security-advisory.md (NOC-1)research/investigations/network-other-config.mdDiscovered and reported by Jakob Wolffhechel, Moksha.