open-iscsi / open-isns - iscsiuio control socket authorization and iSNS record handling: Three related defects

Impact

Three related defects in the initiator stack that ships on every Linux host doing iSCSI. Unprivileged local users can use the iscsiuio control socket, which controls the iSCSI offload/boot path on the NIC. A path-traversal issue lets a machine-in-the-middle attacker cause root-owned files to be created outside the iSCSI node database and inject lines into a record, which means an on-path attacker on the storage network can influence which target the host connects to on subsequent boots. And a double free in open-isns lets an unauthenticated MITM crash the daemon. For a GPU fleet where nodes boot or mount datasets over iSCSI, the middle one is the sharp end: it turns a passive network position into control over what a node believes its storage is.

Who can reach it

Local unprivileged user on the initiator host for the socket issue; machine-in-the-middle on the unauthenticated, unencrypted storage network for the path traversal and the open-isns double free.

What to do

Package update for open-iscsi and open-isns on every initiator - i.e. every GPU node. It is a userspace daemon update, so a restart of iscsiuio/iscsid rather than a reboot, though sessions established through the offload path may need to be re-established. Disable iscsiuio entirely on hosts that do not use hardware iSCSI offload - most do not, and that removes the local-privilege surface outright. The MITM issues are an argument for CHAP mutual authentication or IPsec on the storage VLAN, since the underlying protocol offers no integrity otherwise.

References