| 2015-12-16 14:58:06 |
Lucian Petrut |
bug |
|
|
added bug |
| 2015-12-16 14:58:54 |
Lucian Petrut |
description |
As the disk number of iSCSI attached disks can change after host reboot, passthrough
attached volumes can get attached in this case.
This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356
One of the issues with this patch is that it only handles SCSI attached disks, for which reason
this issue continues to occur when having generation 1 VMs booted from volume, in which
case the disk will be placed on the IDE controller.
In this case, one instance may end up booting from another tenant's volume, which is
a critical security issue.
Also, it assumes that the block device info volume order matches the according disk
controller slot order, which is wrong.
Related bug: https://bugs.launchpad.net/nova/+bug/1322926 |
As the disk number of iSCSI attached disks can change after host reboot, passthrough attached volumes can get attached in this case.
This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356
One of the issues with this patch is that it only handles SCSI attached disks, for which reason this issue continues to occur when having generation 1 VMs booted from volume, in which case the disk will be placed on the IDE controller.
In this case, one instance may end up booting from another tenant's volume, which is a critical security issue.
Also, it assumes that the block device info volume order matches the according disk controller slot order, which is wrong.
Related bug: https://bugs.launchpad.net/nova/+bug/1322926 |
|
| 2015-12-16 14:59:17 |
Lucian Petrut |
nova: assignee |
|
Lucian Petrut (petrutlucian94) |
|
| 2015-12-16 15:08:00 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2015-12-16 15:08:38 |
Tristan Cacqueray |
description |
As the disk number of iSCSI attached disks can change after host reboot, passthrough attached volumes can get attached in this case.
This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356
One of the issues with this patch is that it only handles SCSI attached disks, for which reason this issue continues to occur when having generation 1 VMs booted from volume, in which case the disk will be placed on the IDE controller.
In this case, one instance may end up booting from another tenant's volume, which is a critical security issue.
Also, it assumes that the block device info volume order matches the according disk controller slot order, which is wrong.
Related bug: https://bugs.launchpad.net/nova/+bug/1322926 |
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.
--
As the disk number of iSCSI attached disks can change after host reboot, passthrough attached volumes can get attached in this case.
This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356
One of the issues with this patch is that it only handles SCSI attached disks, for which reason this issue continues to occur when having generation 1 VMs booted from volume, in which case the disk will be placed on the IDE controller.
In this case, one instance may end up booting from another tenant's volume, which is a critical security issue.
Also, it assumes that the block device info volume order matches the according disk controller slot order, which is wrong.
Related bug: https://bugs.launchpad.net/nova/+bug/1322926 |
|
| 2015-12-16 15:09:19 |
Tristan Cacqueray |
ossa: status |
New |
Incomplete |
|
| 2015-12-16 15:09:30 |
Tristan Cacqueray |
bug |
|
|
added subscriber Nova Core security contacts |
| 2015-12-22 04:16:06 |
Tony Breeds |
bug |
|
|
added subscriber Claudiu Belu |
| 2015-12-22 04:16:50 |
Tony Breeds |
bug |
|
|
added subscriber Alessandro Pilotti |
| 2016-01-04 15:50:56 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Won't Fix |
|
| 2016-01-04 15:51:00 |
Tristan Cacqueray |
information type |
Private Security |
Public |
|
| 2016-01-04 16:07:28 |
Alessandro Pilotti |
nova: importance |
Undecided |
High |
|
| 2016-01-04 16:07:34 |
Alessandro Pilotti |
nova: status |
New |
Incomplete |
|
| 2016-01-04 16:07:44 |
Alessandro Pilotti |
nova: status |
Incomplete |
In Progress |
|
| 2016-02-25 19:15:31 |
OpenStack Infra |
nova: status |
In Progress |
Fix Released |
|
| 2020-02-28 00:00:26 |
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.
--
As the disk number of iSCSI attached disks can change after host reboot, passthrough attached volumes can get attached in this case.
This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356
One of the issues with this patch is that it only handles SCSI attached disks, for which reason this issue continues to occur when having generation 1 VMs booted from volume, in which case the disk will be placed on the IDE controller.
In this case, one instance may end up booting from another tenant's volume, which is a critical security issue.
Also, it assumes that the block device info volume order matches the according disk controller slot order, which is wrong.
Related bug: https://bugs.launchpad.net/nova/+bug/1322926 |
As the disk number of iSCSI attached disks can change after host reboot, passthrough attached volumes can get attached in this case.
This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356
One of the issues with this patch is that it only handles SCSI attached disks, for which reason this issue continues to occur when having generation 1 VMs booted from volume, in which case the disk will be placed on the IDE controller.
In this case, one instance may end up booting from another tenant's volume, which is a critical security issue.
Also, it assumes that the block device info volume order matches the according disk controller slot order, which is wrong.
Related bug: https://bugs.launchpad.net/nova/+bug/1322926 |
|
