A pool-operator can overwrite the host's iSCSI initiator identity by injecting an arbitrary IQN via PBD.device_config:localIQN. The SM driver calls iscsilib.set_IQN() which writes the attacker-supplied value to /etc/iscsi/initiatorname.iscsi - the host's persistent iSCSI identity file. All subsequent iSCSI operations from the host use the spoofed IQN, bypassing storage array access controls based on initiator identity. Enterprise storage arrays (NetApp, Dell EMC, Pure Storage, HPE) commonly use IQN-based ACLs as the primary access control mechanism for iSCSI LUNs.
When creating an iSCSI SR, the SM driver reads device_config:localIQN to determine the host's iSCSI initiator name. The value flows from the XAPI database to a file write on the host filesystem with no validation.
SR.create(device_config={..., localIQN: "iqn.attacker.example:impersonate"})
-> PBD stored with unchecked localIQN value
-> PBD.plug() triggers BaseISCSI.load()
-> iscsilib.set_IQN("iqn.attacker.example:impersonate")
-> Writes to /etc/iscsi/initiatorname.iscsi
-> All subsequent iSCSI operations use the spoofed IQN
-> Storage array ACLs based on IQN are bypassed
The iscsilib.set_IQN() function opens /etc/iscsi/initiatorname.iscsi and writes the attacker-supplied IQN as the new initiator name. This change persists across reboots and affects all iSCSI connections from the host, not just the SR being created.
The injected IQN can match any other host's initiator name. This allows the attacker to:
No IQN format validation. The SM driver accepts any string as a localIQN value. No check enforces RFC 3720 IQN format, no check verifies the value matches the host's legitimate identity.
Global host identity modification via storage operation. A storage SR creation call permanently modifies the host's iSCSI identity, affecting all iSCSI operations - not just the SR being created.
File-system persistence. The change is written to /etc/iscsi/initiatorname.iscsi and persists across reboots. Removing the PBD or SR does not restore the original IQN.
Storage array trust model. Enterprise iSCSI arrays use initiator IQN as the primary identity for access control. The XAPI-to-storage trust chain assumes the initiator IQN is controlled by the system administrator, not by any user with pool-operator credentials.
| Scenario | Impact | Pre-conditions | Status |
|---|---|---|---|
| IQN spoofing - same pool | Access LUNs authorized for another host | Multi-host pool with iSCSI storage | ALL PASS (live-tested) |
| IQN spoofing - cross-pool | Access LUNs authorized for hosts in other pools | Shared iSCSI SAN | Modeled (same mechanism) |
| Persistent identity theft | Spoofed IQN persists across reboots | None | ALL PASS (live-tested) |
| BOC-1 chain | vm-admin escalates to pool-operator via BOC-1 S3, then spoofs IQN | BOC-1 available | Modeled (two-step chain) |
/etc/iscsi/initiatorname.iscsi for unexpected changes on all hostsPBD.device_config for localIQN keys that do not match the host's assigned IQNpool-operator role grants to trusted storage administrators/etc/iscsi/initiatorname.iscsiReject localIQN in device_config. The host's iSCSI identity should not be modifiable through storage operations. Remove localIQN support from the SM driver, or restrict it to _R_POOL_ADMIN only with RFC 3720 format validation.
IQN immutability. The host's iSCSI initiator name should be set once during host installation and not modifiable via the API.
Storage array coordination. Notify iSCSI storage vendors that XAPI-based hosts can have their initiator IQN spoofed, so IQN-only ACLs are insufficient when XAPI users have pool-operator access.
Upstream patches exist. They are held privately pending coordinated disclosure.
Disclosure:
iscsilib.py:set_IQN() (IQN file write), BaseISCSI.py:load() (localIQN read from device_config)disclosure/advisories/pdc-security-advisory.md (PDC-6)research/investigations/pbd-device-config.mdresearch/pdc-6/poc/pdc-6-iqn-injection.py (available to CSIRTs on request)pdc-6-iqn-injection-20260322-010620.logDiscovered and reported by Jakob Wolffhechel, Moksha.