[OSSA-2018-001] Swapping encrypted volumes can lead to data loss and a possible compute host DOS attack (CVE-2017-18191)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Critical
|
Lee Yarwood | ||
Ocata |
Fix Released
|
High
|
Lee Yarwood | ||
Pike |
Fix Released
|
High
|
Lee Yarwood | ||
Queens |
Fix Released
|
High
|
Lee Yarwood | ||
OpenStack Security Advisory |
Fix Released
|
Critical
|
Jeremy Stanley |
Bug Description
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):
https:/
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-
Steps to reproduce
==================
- Create two encrypted volumes
$ cinder type-create LUKS
$ cinder encryption-
$ cinder type-create LUKS_NEW
$ cinder encryption-
$ cinder create --volume-type LUKS 1
$ cinder create --volume-type LUKS_NEW 1
- Spawn an instance, attaching the first volume before swapping to the second:
$ nova boot --image cirros-
$ 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
-------
vda /opt/stack/
vdb /dev/disk/
$ ll /dev/disk/
lrwxrwxrwx. 1 root root 9 Dec 21 05:30 /dev/disk/
$ sudo qemu-img info /dev/disk/
image: /dev/disk/
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 volumes.
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.
Environment
===========
1. Exact version of OpenStack you are running. See the following
list for all releases: http://
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?
LVM
3. Which networking type did you use?
(For example: nova-network, Neutron with OpenVSwitch, ...)
N/A
Logs & Configs
==============
N/A
CVE References
Changed in ossa: | |
status: | New → Incomplete |
description: | updated |
summary: |
Swapping encrypted volumes can lead to data loss and a possible compute - host DOS attack + host DOS attack (CVE-2017-18191) |
summary: |
- Swapping encrypted volumes can lead to data loss and a possible compute - host DOS attack (CVE-2017-18191) + [OSSA-2018-001] Swapping encrypted volumes can lead to data loss and a + possible compute host DOS attack (CVE-2017-18191) |
Changed in ossa: | |
status: | Incomplete → Fix Committed |
Changed in ossa: | |
importance: | Undecided → Critical |
assignee: | nobody → Jeremy Stanley (fungi) |
status: | Fix Committed → Fix Released |
I think the priority here is that the user loses their data. The DoS potential is real, but relatively inefficient. I think we could use a CVE to communicate the problem to users, but I don't think this particular issue is important enough to jump through secrecy hoops while we work on the data-loss bug.
I would personally be in favour of early disclosure, handling this openly, and getting it done quickly. We could possibly leave disclosure til early January, though, as we're unlikely to even start work on the fix until then. I'll obviously defer to the VMT and the reporter, just my 2c.