CVE-2023-2088 for Ubuntu Openstack

Corey Bryant corey.bryant at
Mon Jul 17 16:19:27 UTC 2023

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 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


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

"is_service": "role:service or
"legacy_system_admin_or_project_member": "(role:admin) or (role:member and
"volume:attachment_delete": "rule:legacy_system_admin_or_project_member and
"rule:legacy_system_admin_or_project_member and rule:is_service"
"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 =

* CVE-2023-2088:
* OSSA-2023-003 Unauthorized volume access through deleted volume
* OSSN-0092 Using Configuration as a Short-Term Mitigation for
* Bug 2004555:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openstack-discuss mailing list