Activity log for bug #1784871

Date Who What changed Old value New value Message
2018-08-01 14:11:15 Eric Harney bug added bug
2018-08-01 14:30:23 Eric Harney attachment added proposed fix (untested) https://bugs.launchpad.net/cinder/+bug/1784871/+attachment/5170355/+files/0001-ScaleIO-Require-zero-padding-to-be-enabled.patch
2018-08-01 14:39:48 Tristan Cacqueray bug task added ossa
2018-08-01 14:40:04 Tristan Cacqueray ossa: status New Incomplete
2018-08-01 14:40:19 Tristan Cacqueray description Bug 1699573 described an issue in the ScaleIO Cinder driver where new volumes can contain data from previously deleted volumes. [1] We specifically document [2] that this is a security hazard for Cinder, because it means that end-user data can leak between tenants. The previous bug discussion and fix indicated that this only affects thick-provisioned volumes from ScaleIO. Further investigation indicates that it also affects thin-provisioned volumes, so the fix was not complete. It appears that we can fix this issue completely by extending the previous fix to not consider thin-provisioned volumes safe, and apply the same logic to thin volumes that we use for thick volumes. This would force ScaleIO zero padding to be enabled in all cases. I also think this bug merits a Class A rating per the VMT process. [3] I don't see a reason we can't backport the fix to stable releases. The text of OSSN-0084 [4] makes this more confusing -- the description described this issue as affecting thin volumes, when the fix only affected thick volumes. The Recommended Actions are also incorrect -- enabling zero padding probably* fixes this issue, but swapping to thin volumes is not relevant. * (I don't have access to a ScaleIO backend to investigate this directly. I'm relying on some brief discussion with ScaleIO maintainers and customer reports.) [1] https://bugs.launchpad.net/cinder/+bug/1699573 [2] https://git.openstack.org/cgit/openstack/cinder/tree/doc/source/contributor/drivers.rst?h=13.0.0.0b2#n58 [3] https://security.openstack.org/vmt-process.html#incident-report-taxonomy [4] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132096.html This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- Bug 1699573 described an issue in the ScaleIO Cinder driver where new volumes can contain data from previously deleted volumes. [1] We specifically document [2] that this is a security hazard for Cinder, because it means that end-user data can leak between tenants. The previous bug discussion and fix indicated that this only affects thick-provisioned volumes from ScaleIO. Further investigation indicates that it also affects thin-provisioned volumes, so the fix was not complete. It appears that we can fix this issue completely by extending the previous fix to not consider thin-provisioned volumes safe, and apply the same logic to thin volumes that we use for thick volumes. This would force ScaleIO zero padding to be enabled in all cases. I also think this bug merits a Class A rating per the VMT process. [3] I don't see a reason we can't backport the fix to stable releases. The text of OSSN-0084 [4] makes this more confusing -- the description described this issue as affecting thin volumes, when the fix only affected thick volumes. The Recommended Actions are also incorrect -- enabling zero padding probably* fixes this issue, but swapping to thin volumes is not relevant. * (I don't have access to a ScaleIO backend to investigate this directly. I'm relying on some brief discussion with ScaleIO maintainers and customer reports.) [1] https://bugs.launchpad.net/cinder/+bug/1699573 [2] https://git.openstack.org/cgit/openstack/cinder/tree/doc/source/contributor/drivers.rst?h=13.0.0.0b2#n58 [3] https://security.openstack.org/vmt-process.html#incident-report-taxonomy [4] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132096.html
2018-08-01 14:40:31 Tristan Cacqueray bug added subscriber Cinder Core security contacts
2018-08-01 15:12:33 Eric Harney bug added subscriber Helen Walsh
2018-08-01 15:45:58 Eric Harney bug added subscriber Matan Sabag
2018-08-02 13:47:19 Eric Harney bug added subscriber Summer Long
2018-08-14 12:46:20 Sean McGinnis cinder: assignee Helen Walsh (walshh2)
2018-08-14 15:04:00 Sean McGinnis cinder: assignee Helen Walsh (walshh2) Matan Sabag (matan-sabag)
2018-08-15 14:09:11 Jay Bryant ossa: status Incomplete Confirmed
2018-08-15 17:58:57 Jeremy Stanley description This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- Bug 1699573 described an issue in the ScaleIO Cinder driver where new volumes can contain data from previously deleted volumes. [1] We specifically document [2] that this is a security hazard for Cinder, because it means that end-user data can leak between tenants. The previous bug discussion and fix indicated that this only affects thick-provisioned volumes from ScaleIO. Further investigation indicates that it also affects thin-provisioned volumes, so the fix was not complete. It appears that we can fix this issue completely by extending the previous fix to not consider thin-provisioned volumes safe, and apply the same logic to thin volumes that we use for thick volumes. This would force ScaleIO zero padding to be enabled in all cases. I also think this bug merits a Class A rating per the VMT process. [3] I don't see a reason we can't backport the fix to stable releases. The text of OSSN-0084 [4] makes this more confusing -- the description described this issue as affecting thin volumes, when the fix only affected thick volumes. The Recommended Actions are also incorrect -- enabling zero padding probably* fixes this issue, but swapping to thin volumes is not relevant. * (I don't have access to a ScaleIO backend to investigate this directly. I'm relying on some brief discussion with ScaleIO maintainers and customer reports.) [1] https://bugs.launchpad.net/cinder/+bug/1699573 [2] https://git.openstack.org/cgit/openstack/cinder/tree/doc/source/contributor/drivers.rst?h=13.0.0.0b2#n58 [3] https://security.openstack.org/vmt-process.html#incident-report-taxonomy [4] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132096.html Bug 1699573 described an issue in the ScaleIO Cinder driver where new volumes can contain data from previously deleted volumes. [1] We specifically document [2] that this is a security hazard for Cinder, because it means that end-user data can leak between tenants. The previous bug discussion and fix indicated that this only affects thick-provisioned volumes from ScaleIO. Further investigation indicates that it also affects thin-provisioned volumes, so the fix was not complete. It appears that we can fix this issue completely by extending the previous fix to not consider thin-provisioned volumes safe, and apply the same logic to thin volumes that we use for thick volumes. This would force ScaleIO zero padding to be enabled in all cases. I also think this bug merits a Class A rating per the VMT process. [3] I don't see a reason we can't backport the fix to stable releases. The text of OSSN-0084 [4] makes this more confusing -- the description described this issue as affecting thin volumes, when the fix only affected thick volumes. The Recommended Actions are also incorrect -- enabling zero padding probably* fixes this issue, but swapping to thin volumes is not relevant. * (I don't have access to a ScaleIO backend to investigate this directly. I'm relying on some brief discussion with ScaleIO maintainers and customer reports.) [1] https://bugs.launchpad.net/cinder/+bug/1699573 [2] https://git.openstack.org/cgit/openstack/cinder/tree/doc/source/contributor/drivers.rst?h=13.0.0.0b2#n58 [3] https://security.openstack.org/vmt-process.html#incident-report-taxonomy [4] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132096.html
2018-08-15 17:59:08 Jeremy Stanley information type Private Security Public Security
2018-08-15 19:01:42 OpenStack Infra cinder: status New In Progress
2018-08-15 21:25:11 OpenStack Infra cinder: assignee Matan Sabag (matan-sabag) Sean McGinnis (sean-mcginnis)
2018-08-15 21:39:27 Sean McGinnis cinder: assignee Sean McGinnis (sean-mcginnis) Matan Sabag (matan-sabag)
2018-08-17 20:18:44 OpenStack Infra cinder: status In Progress Fix Released
2018-08-20 15:37:47 OpenStack Infra tags in-stable-rocky
2018-08-21 23:17:22 Summer Long cve linked 2017-15139
2018-09-11 19:35:44 OpenStack Infra tags in-stable-rocky in-stable-queens in-stable-rocky
2018-09-20 22:10:11 OpenStack Infra tags in-stable-queens in-stable-rocky in-stable-pike in-stable-queens in-stable-rocky
2018-09-21 15:51:55 OpenStack Infra tags in-stable-pike in-stable-queens in-stable-rocky in-stable-ocata in-stable-pike in-stable-queens in-stable-rocky
2018-10-03 04:35:55 OpenStack Infra tags in-stable-ocata in-stable-pike in-stable-queens in-stable-rocky in-driverfixes-newton in-stable-ocata in-stable-pike in-stable-queens in-stable-rocky
2021-01-21 17:16:15 Jeremy Stanley ossa: status Confirmed Won't Fix