Activity log for bug #1739593

Date Who What changed Old value New value Message
2017-12-21 10:54:00 Lee Yarwood bug added bug
2017-12-21 11:03:34 Lee Yarwood bug added subscriber Matthew Booth
2017-12-21 14:13:15 Tristan Cacqueray bug task added ossa
2017-12-21 14:13:20 Tristan Cacqueray ossa: status New Incomplete
2017-12-21 14:13:50 Tristan Cacqueray 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: https://github.com/openstack/nova/blob/76dfdfc1ad8c0e5376bd997e45f65bec9ff53d12/nova/virt/libvirt/driver.py#L1338-L1372 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: https://github.com/openstack/os-brick/blob/6835b885dc4144fdc6e9863ca59ae54f76938995/os_brick/encryptors/luks.py#L138-L161 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://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf 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 second: $ 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 ------------------------------------------------ vda /opt/stack/data/nova/instances/3d4c5842-45ab-4660-bf6e-9459f9a2ff8a/disk 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 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://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? LVM 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs ============== N/A 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. -- 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: https://github.com/openstack/nova/blob/76dfdfc1ad8c0e5376bd997e45f65bec9ff53d12/nova/virt/libvirt/driver.py#L1338-L1372 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: https://github.com/openstack/os-brick/blob/6835b885dc4144fdc6e9863ca59ae54f76938995/os_brick/encryptors/luks.py#L138-L161 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://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf 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 second: $ 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 ------------------------------------------------ vda /opt/stack/data/nova/instances/3d4c5842-45ab-4660-bf6e-9459f9a2ff8a/disk 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 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://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?    LVM 3. Which networking type did you use?    (For example: nova-network, Neutron with OpenVSwitch, ...)    N/A Logs & Configs ============== N/A
2017-12-21 14:14:01 Tristan Cacqueray bug added subscriber Nova Core security contacts
2017-12-21 16:04:50 Jeremy Stanley bug added subscriber OSSG CoreSec
2018-01-04 18:48:02 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. -- 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: https://github.com/openstack/nova/blob/76dfdfc1ad8c0e5376bd997e45f65bec9ff53d12/nova/virt/libvirt/driver.py#L1338-L1372 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: https://github.com/openstack/os-brick/blob/6835b885dc4144fdc6e9863ca59ae54f76938995/os_brick/encryptors/luks.py#L138-L161 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://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf 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 second: $ 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 ------------------------------------------------ vda /opt/stack/data/nova/instances/3d4c5842-45ab-4660-bf6e-9459f9a2ff8a/disk 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 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://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?    LVM 3. Which networking type did you use?    (For example: nova-network, Neutron with OpenVSwitch, ...)    N/A Logs & Configs ============== N/A 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: https://github.com/openstack/nova/blob/76dfdfc1ad8c0e5376bd997e45f65bec9ff53d12/nova/virt/libvirt/driver.py#L1338-L1372 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: https://github.com/openstack/os-brick/blob/6835b885dc4144fdc6e9863ca59ae54f76938995/os_brick/encryptors/luks.py#L138-L161 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://gitlab.com/cryptsetup/cryptsetup/wikis/LUKS-standard/on-disk-format.pdf 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 second: $ 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 ------------------------------------------------ vda /opt/stack/data/nova/instances/3d4c5842-45ab-4660-bf6e-9459f9a2ff8a/disk 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 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://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?    LVM 3. Which networking type did you use?    (For example: nova-network, Neutron with OpenVSwitch, ...)    N/A Logs & Configs ============== N/A
2018-01-04 18:48:12 Jeremy Stanley information type Private Security Public Security
2018-01-04 19:17:49 Eric Harney bug added subscriber Eric Harney
2018-01-04 20:20:27 OpenStack Infra nova: status New In Progress
2018-01-04 20:20:27 OpenStack Infra nova: assignee Lee Yarwood (lyarwood)
2018-01-22 16:07:09 Jay Pipes nova: importance Undecided Critical
2018-01-22 22:21:41 OpenStack Infra nova: status In Progress Fix Released
2018-01-25 15:37:46 Matt Riedemann bug watch added https://bugzilla.redhat.com/show_bug.cgi?id=760547
2018-02-20 00:31:37 Tristan Cacqueray summary Swapping encrypted volumes can lead to data loss and a possible compute host DOS attack Swapping encrypted volumes can lead to data loss and a possible compute host DOS attack (CVE-2017-18191)
2018-02-20 13:11:00 Tristan Cacqueray cve linked 2017-18191
2018-04-12 16:22:48 Matt Riedemann nominated for series nova/queens
2018-04-12 16:22:48 Matt Riedemann bug task added nova/queens
2018-04-12 16:22:48 Matt Riedemann nominated for series nova/ocata
2018-04-12 16:22:48 Matt Riedemann bug task added nova/ocata
2018-04-12 16:22:48 Matt Riedemann nominated for series nova/pike
2018-04-12 16:22:48 Matt Riedemann bug task added nova/pike
2018-04-12 16:22:56 Matt Riedemann nova/pike: status New In Progress
2018-04-12 16:23:01 Matt Riedemann nova/pike: assignee Lee Yarwood (lyarwood)
2018-04-12 16:23:08 Matt Riedemann nova/queens: status New Fix Released
2018-04-12 16:23:14 Matt Riedemann nova/queens: assignee Lee Yarwood (lyarwood)
2018-04-12 16:23:16 Matt Riedemann nova/ocata: status New Confirmed
2018-04-12 16:23:21 Matt Riedemann nova/pike: importance Undecided High
2018-04-12 16:23:24 Matt Riedemann nova/ocata: importance Undecided High
2018-04-12 16:23:28 Matt Riedemann nova/queens: importance Undecided High
2018-04-12 16:23:39 Matt Riedemann nova/ocata: assignee Lee Yarwood (lyarwood)
2018-04-16 12:31:34 OpenStack Infra nova/ocata: status Confirmed In Progress
2018-04-17 14:30:00 OpenStack Infra nova/pike: assignee Lee Yarwood (lyarwood) Matt Riedemann (mriedem)
2018-04-17 14:30:30 Matt Riedemann nova/pike: assignee Matt Riedemann (mriedem) Lee Yarwood (lyarwood)
2018-04-17 20:52:35 OpenStack Infra nova/pike: status In Progress Fix Committed
2018-04-18 19:58:04 OpenStack Infra nova/ocata: assignee Lee Yarwood (lyarwood) Matt Riedemann (mriedem)
2018-04-18 19:58:19 Matt Riedemann nova/ocata: assignee Matt Riedemann (mriedem) Lee Yarwood (lyarwood)
2018-04-20 05:25:03 OpenStack Infra nova/ocata: status In Progress Fix Committed
2018-04-20 14:46:50 Tristan Cacqueray 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)
2018-04-23 02:24:12 Tristan Cacqueray ossa: status Incomplete Fix Committed
2019-04-12 18:02:37 Jeremy Stanley ossa: importance Undecided Critical
2019-04-12 18:02:52 Jeremy Stanley ossa: assignee Jeremy Stanley (fungi)
2019-04-12 18:02:57 Jeremy Stanley ossa: status Fix Committed Fix Released