Open Stack

Ahh, yes there were no subsequent objections to switching this bug to
public, so I'll do that now and triage as a class B1 report. The
security notes editors may want to consider drafting an OSSN related to
this when it gets fixed in master.

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Description changed:

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

** Tags added: security

-- 
You received this bug notification because you are a member of OpenStack
Security SIG, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1739646

Title:
  Instance type with disk set to 0 can cause DoS

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Won't Fix

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1739646/+subscriptions