Bug LP:#2004555 (CVE-2023-2088) identified that “an unauthorised access to a volume could occur when an iSCSI or FC connection from a host is severed due to a volume being unmapped on the storage system and the device is later reused for another volume on the same host”.

While the bug affects iSCSI and FC, the fix introduces a breaking change for configurations upgrading to the fixed packages if they do not have service token support enabled. The new code introduces mandatory use of service tokens to identify requests coming from a trusted control plane service.

Service tokens are issued by Keystone for service users. For example, a token can be issued to the Nova service user. They have a particular trust level, defined by the service, that allows them to perform trusted actions. In the case of Nova, the action is detaching volumes from instances.

Versions of Ubuntu OpenStack for Yoga and later will have new packages versions released with CVE patches applied that require the use of service tokens to enable the detaching and deletion of volumes on instances. These packages will be released on July 24, 2023.

Versions of Ubuntu OpenStack for Xena and earlier will not have package updates released and will still be vulnerable to the “unauthorised detach of volumes” issue until a mitigation policy is applied. The mitigation policy provided requires the use of service tokens.

= Patched packages =

The following package versions include patches for CVE-2023-2088. These package versions deliver services that require the use of service tokens. Package versions prior to those listed will not be patched for CVE-2023-2088 and will therefore require policy updates for mitigation.

Ubuntu 23.04 (Lunar)
* nova >= 3:27.0.0-0ubuntu1.3
* cinder >= 2:22.0.0-0ubuntu1.3
* python-os-brick >= 6.2.0-0ubuntu2.3
* ironic >= 1:21.4.0-0ubuntu1.1
* python-glance-store >= 4.3.0-0ubuntu1.3

Ubuntu Cloud Archive Antelope
* nova >= 3:27.0.0-0ubuntu1.3~cloud0
* cinder >= 2:22.0.0-0ubuntu1.3~cloud0
* python-os-brick >= 6.2.0-0ubuntu2.3~cloud0
* ironic >= 1:21.4.0-0ubuntu1.1~cloud0
* python-glance-store >= 4.3.0-0ubuntu1.3~cloud0

Ubuntu 22.10 (Kinetic)
* nova >= 3:26.1.1-0ubuntu1.1
* cinder >= 2:21.2.0-0ubuntu1.1
* python-os-brick >= os-brick - 6.1.0-0ubuntu1.3
* ironic >= 1:21.1.0-0ubuntu1.1
* python-glance-store >= 4.1.0-0ubuntu1.3

Ubuntu Cloud Archive Zed
* nova >= 3:26.1.1-0ubuntu1.1~cloud0
* cinder >= 2:21.2.0-0ubuntu1.1~cloud0
* python-os-brick >= os-brick - 6.1.0-0ubuntu1.3~cloud0
* ironic >= 1:21.1.0-0ubuntu1.1~cloud0
* python-glance-store >= 4.1.0-0ubuntu1.3~cloud0

Ubuntu 22.04 (Jammy)
* nova >= 3:25.1.1-0ubuntu1.1
* cinder >= 2:20.2.0-0ubuntu1.1
* python-os-brick >= 5.2.2-0ubuntu1.2
* ironic >= 1:20.1.0-0ubuntu1.1
* python-glance-store >= 3.0.0-0ubuntu1.3

Ubuntu Cloud Archive Yoga
* nova >= 3:25.1.1-0ubuntu1.1~cloud0
* cinder >= 2:20.2.0-0ubuntu1.1~cloud0
* python-os-brick >= 5.2.2-0ubuntu1.2~cloud0
* ironic >= 1:20.1.0-0ubuntu1.1~cloud0
* python-glance-store >= 3.0.0-0ubuntu1.3~cloud0

= Using a custom Cinder policy as a mitigation =

It’s possible to restrict the access to the operations affected by this CVE by providing a custom Cinder policy file that will prevent users from deleting attachments, detach and force detach. In order to use this mitigation, service token support must be enabled. The exact method for customising this depends on the deployment tooling being used. The following steps can be used as a guildeline:

1) Identify the nova service user id running the following command

openstack user show --domain service_domain -f value -c id nova

The command output looks like this

ae034831d6bf41099327bf9d34988fbc

2) Create and apply the following policy to cinder, using the output of the previous command:

"is_service": "role:service or service_user_id:ae034831d6bf41099327bf9d34988fbc"
"legacy_system_admin_or_project_member": "(role:admin) or (role:member and project_id:%(project_id)s)"
"volume:attachment_delete": "rule:legacy_system_admin_or_project_member and rule:is_service"
"volume_extension:volume_actions:terminate_connection": "rule:legacy_system_admin_or_project_member and rule:is_service"
"volume_extension:volume_actions:detach": "rule:legacy_system_admin_or_project_member and rule:is_service"
"volume_extension:volume_admin_actions:force_detach": "!"

= Frequently Asked Questions =

Q: What can I do if my deployed cloud doesn’t have service tokens enabled and my deployment tooling doesn’t have the option to enable them?
A: Pin the version of the affected packages to block the upgrades to the versions listed in “Affected packages” section or newer, until service tokens are enabled.

= References =