| 2017-12-21 17:23:34 |
Mohammed Naser |
bug |
|
|
added bug |
| 2017-12-21 17:24:25 |
Mohammed Naser |
bug |
|
|
added subscriber Matt Riedemann |
| 2017-12-21 17:29:38 |
Matt Riedemann |
bug |
|
|
added subscriber Matthew Booth |
| 2017-12-21 17:38:04 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2017-12-21 17:38:52 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2017-12-21 17:39:14 |
Jeremy Stanley |
bug |
|
|
added subscriber Nova Core security contacts |
| 2017-12-21 17:40:32 |
Jeremy Stanley |
description |
In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following:
"The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes."
In a cloud environment where a deployer wants to offer boot-from-volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage).
I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types.
I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. |
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.
In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following:
"The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes."
In a cloud environment where a deployer wants to offer boot-from-volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage).
I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types.
I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. |
|
| 2018-02-16 14:57:54 |
Jeremy Stanley |
bug |
|
|
added subscriber OSSG CoreSec |
| 2018-04-13 15:50:57 |
Jeremy Stanley |
information type |
Private Security |
Public |
|
| 2018-04-13 15:51:07 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2018-04-13 15:51:17 |
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.
In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following:
"The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes."
In a cloud environment where a deployer wants to offer boot-from-volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage).
I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types.
I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. |
In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following:
"The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes."
In a cloud environment where a deployer wants to offer boot-from-volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage).
I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types.
I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. |
|
| 2018-04-13 15:51:30 |
Jeremy Stanley |
tags |
|
security |
|
| 2018-04-13 16:28:20 |
Matt Riedemann |
nova: status |
New |
Triaged |
|
| 2018-04-13 16:28:27 |
Matt Riedemann |
nominated for series |
|
nova/ocata |
|
| 2018-04-13 16:28:27 |
Matt Riedemann |
bug task added |
|
nova/ocata |
|
| 2018-04-13 16:28:27 |
Matt Riedemann |
nominated for series |
|
nova/pike |
|
| 2018-04-13 16:28:27 |
Matt Riedemann |
bug task added |
|
nova/pike |
|
| 2018-04-13 16:28:27 |
Matt Riedemann |
nominated for series |
|
nova/queens |
|
| 2018-04-13 16:28:27 |
Matt Riedemann |
bug task added |
|
nova/queens |
|
| 2018-04-13 16:28:34 |
Matt Riedemann |
nova/ocata: status |
New |
Triaged |
|
| 2018-04-13 16:28:37 |
Matt Riedemann |
nova/queens: status |
New |
Triaged |
|
| 2018-04-13 16:28:40 |
Matt Riedemann |
nova/pike: status |
New |
Triaged |
|
| 2018-04-13 16:28:44 |
Matt Riedemann |
nova/pike: importance |
Undecided |
High |
|
| 2018-04-13 16:28:50 |
Matt Riedemann |
nova: assignee |
|
Matt Riedemann (mriedem) |
|
| 2018-04-13 16:28:54 |
Matt Riedemann |
nova/queens: importance |
Undecided |
High |
|
| 2018-04-13 16:29:59 |
Jeremy Stanley |
information type |
Public |
Public Security |
|
| 2018-04-13 16:30:10 |
Jeremy Stanley |
ossa: status |
Won't Fix |
Incomplete |
|
| 2018-04-13 16:30:26 |
Jeremy Stanley |
tags |
security |
|
|
| 2018-04-13 16:45:10 |
Matt Riedemann |
nova: importance |
Undecided |
High |
|
| 2018-04-13 16:45:11 |
Matt Riedemann |
nova/ocata: importance |
Undecided |
High |
|
| 2018-04-13 17:54:42 |
OpenStack Infra |
nova: status |
Triaged |
In Progress |
|
| 2018-04-23 16:21:21 |
OpenStack Infra |
nova/queens: status |
Triaged |
In Progress |
|
| 2018-04-23 16:21:21 |
OpenStack Infra |
nova/queens: assignee |
|
Matt Riedemann (mriedem) |
|
| 2018-04-23 17:06:02 |
OpenStack Infra |
nova/pike: status |
Triaged |
In Progress |
|
| 2018-04-23 17:06:02 |
OpenStack Infra |
nova/pike: assignee |
|
Matt Riedemann (mriedem) |
|
| 2018-04-23 17:49:18 |
OpenStack Infra |
nova/ocata: status |
Triaged |
In Progress |
|
| 2018-04-23 17:49:18 |
OpenStack Infra |
nova/ocata: assignee |
|
Matt Riedemann (mriedem) |
|
| 2018-04-24 17:39:50 |
Jeremy Stanley |
information type |
Public Security |
Public |
|
| 2018-04-24 17:40:00 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2018-04-24 17:40:15 |
Jeremy Stanley |
bug task added |
|
ossn |
|
| 2018-04-24 17:40:34 |
Jeremy Stanley |
tags |
|
security |
|
| 2018-06-19 12:01:19 |
OpenStack Infra |
nova: status |
In Progress |
Fix Released |
|
| 2018-06-25 03:00:07 |
OpenStack Infra |
nova/queens: status |
In Progress |
Fix Committed |
|
| 2018-06-29 08:52:24 |
OpenStack Infra |
nova/pike: status |
In Progress |
Fix Committed |
|
| 2018-07-04 14:54:32 |
OpenStack Infra |
nova/ocata: status |
In Progress |
Fix Committed |
|
