I'm +1 now on the stable/pike backport
https://review.openstack.org/#/c/543569/ - my +2 is pending discussion
about a 'security' release note in the patch that mentions the CVE /
OSSA which isn't yet published, and sounds like we might have a chicken-
and-egg with that until the stable/ocata backport is proposed?

** Also affects: nova/queens
   Importance: Undecided
       Status: New

** Also affects: nova/ocata
   Importance: Undecided
       Status: New

** Also affects: nova/pike
   Importance: Undecided
       Status: New

** Changed in: nova/pike
       Status: New => In Progress

** Changed in: nova/pike
     Assignee: (unassigned) => Lee Yarwood (lyarwood)

** Changed in: nova/queens
       Status: New => Fix Released

** Changed in: nova/queens
     Assignee: (unassigned) => Lee Yarwood (lyarwood)

** Changed in: nova/ocata
       Status: New => Confirmed

** Changed in: nova/pike
   Importance: Undecided => High

** Changed in: nova/ocata
   Importance: Undecided => High

** Changed in: nova/queens
   Importance: Undecided => High

** Changed in: nova/ocata
     Assignee: (unassigned) => Lee Yarwood (lyarwood)

You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).

  Swapping encrypted volumes can lead to data loss and a possible
  compute host DOS attack (CVE-2017-18191)

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) ocata series:
Status in OpenStack Compute (nova) pike series:
  In Progress
Status in OpenStack Compute (nova) queens series:
  Fix Released
Status in OpenStack Security Advisory:

Bug description:

  At present when swapping encrypted volumes no attempt is made to
  attach an encryptor to the target volume. This results in the RAW
  underlying volume being used during the rebase, where decrypted data
  is copied from the original volume to the target:


  Any attempt to detach and then reattach this volume from the instance
  will lead to the volume being reformatted as the os-brick supplied
  encryptors do not identify the volume as encrypted:


  Additionally, while unlikely, a malicious user could easily DOS the
  compute node hosting the instance by writing a corrupt LUKS header to
  the RAW volume before detaching and reattaching the volume. For
  example, setting a keyslot iters (used by PBKDF2) to a large value etc
  (kudos to mdbooth for suggesting this):


  This method of DOS'ing the compute host was previously discussed in
  the context of bug 1724573 but dismissed as access to the underlying
  volume was dependent on a host reboot, outside of a users control.
  This bug differs as a user has full control of the above volume-
  update/swap_volume flow that provides access to the underlying volume.

  Steps to reproduce

  - Create two encrypted volumes

  $ cinder type-create LUKS
  $ cinder encryption-type-create --cipher aes-xts-plain64 \
                                  --key_size 256 \
                                  --control_location front-end LUKS luks

  $ cinder type-create LUKS_NEW
  $ cinder encryption-type-create --cipher aes-xts-plain64 \
                                  --key_size 256 \
                                  --control_location front-end LUKS_NEW luks

  $ cinder create --volume-type LUKS 1
  $ cinder create --volume-type LUKS_NEW 1

  - Spawn an instance, attaching the first volume before swapping to the

  $ nova boot --image cirros-0.3.5-x86_64-disk --flavor 1 swap_test
  $ nova volume-attach $instance $vol-luks
  $ nova volume-update $instance $vol-luks $vol-luks-new

  - Review the resulting volume attachment on the compute host:

  $ virsh domblklist $instance
  Target     Source
  vdb        /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c

  $ ll /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c
  lrwxrwxrwx. 1 root root 9 Dec 21 05:30 
/dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c -> ../../sdd

  $ sudo qemu-img info /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c
  image: /dev/disk/by-id/scsi-36001405ba072cc9f93e444c9433ead1c
  file format: raw
  virtual size: 1.0G (1073741824 bytes)
  disk size: 0

  Expected result

  The encrypted volumes are rebased with their associated encryptors
  attached, leading to encrypted data being written to the underlying

  Actual result

  Decrypted data from the source volume is written to the underlying
  target volume. This data will be lost with a subsequent detach /
  attach cycle. Access to the underlying volume could also be used by a
  malicious user to DOS the local compute host.

  1. Exact version of OpenStack you are running. See the following
    list for all releases: http://docs.openstack.org/releases/

  2. Which hypervisor did you use?
     (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
     What's the version of that?

     Libvirt + KVM

  2. Which storage type did you use?
     (For example: Ceph, LVM, GPFS, ...)
     What's the version of that?


  3. Which networking type did you use?
     (For example: nova-network, Neutron with OpenVSwitch, ...)


  Logs & Configs


To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to