Summary Certain storage volume configurations allow newly created volumes to contain previous data. This could lead to leakage of sensitive information between tenants. Affected Services / Software Cinder releases up to and including Queens with ScaleIO volumes using thin volumes and zero padding. External references: https://wiki.openstack.org/wiki/OSSN/OSSN-0084 Upstream bug: https://bugs.launchpad.net/ossn/+bug/1699573
upstream fix: https://git.openstack.org/cgit/openstack/cinder/commit/?id=5492e2206a7736079279f45e9c8b931ca19fb322
The 2018 upstream fix prevents the creation of thick volumes with disabled zero padding by default (although can be overridden with config option, sio_allow_non_padded_thick_volumes). https://git.openstack.org/cgit/openstack/cinder/commit/?id=7feb62197d371ab7253dc86a34af6ff8b484b4df Note: fix is in 13 dev milestone, to be released with Rocky.
Created openstack-cinder tracking bugs for this issue: Affects: openstack-rdo [bug 1610143]
Upstream bug for thin volumes: https://bugs.launchpad.net/cinder/+bug/1784871 Upstream patch (scaleIO):https://review.openstack.org/#/c/592001/ Upstream rocky (not merged yet): https://review.openstack.org/593188
Next patch: https://review.openstack.org/#/c/593694/
Upstream queens: https://review.openstack.org/596879
Upstream pike: https://review.openstack.org/601681
Upstream ocata: https://review.openstack.org/#/c/604105/
Upstream newton: https://review.openstack.org/#/c/606130/
Mitigation: This flaw only affects Red Hat OpenStack Platform deployments which use the third-party EMC ScaleIO driver plugin. To mitigate this flaw, ensure all volumes use zero-padding by updating the ScaleIO storage-pool policy. Note: Only an empty pool's policy can be changed. ~~~ scli --modify_zero_padding_policy (((--protection_domain_id <ID> | --protection_domain_name <NAME>) --storage_pool_name <NAME>) | --storage_pool_id <ID>) (--enable_zero_padding | --disable_zero_padding) Example: scli --modify_zero_padding_policy --protection_domain_name pd10 --storage_pool_name scale1 --enable_zero_padding ~~~
Statement: With this update, disabled zero-padding is no longer the default for new volumes. Users can override this behavior by setting the new configuration item, "sio_allow_non_padded_volumes=True". However, the default should not be overridden if multiple tenants will be using volumes from a shared Storage Pool.
This issue has been addressed in the following products: Red Hat OpenStack Platform 13.0 (Queens) Via RHSA-2018:3601 https://access.redhat.com/errata/RHSA-2018:3601
Tomas, sorry for the wrong update. OpenStack Vulnerability Management Team keep the bug is still only in the "Confirmed" state. OpenStack Gerrit 592001, 593694 and 596658 were already backported to OSP10.
This issue has been addressed in the following products: Red Hat OpenStack Platform 10.0 (Newton) Via RHSA-2019:0917 https://access.redhat.com/errata/RHSA-2019:0917
1. What specific Red Hat OpenStack Platform version to validate? From the bug, https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-15139 , the fix is in ‘cinder 10.0.8, cinder 13.0.0.0rc2, cinder 12.04’, but I’m not sure what version we’re talking about. 2. What specific ScaleIO/VxFlexOS array version to validate? 3. What specific ScaleIO/VxFlexOS deployment option to validate, although I think 2-layer should be good for validate the fix. • 2-layer storage? This is when the ScaleIO/VxFlexOS Storage is installed in separate servers outside of Openstack nodes. • Or Hyperconverged? This is when the Openstack and storage is installed in the same servers.