Hyper-V: swapped disks after host reboot

[Lucian Petrut]

As the disk number of iSCSI attached disks can change after host reboot, passthrough attached volumes can get attached in this case.

This bug was partially fixed during Icehouse by this patch:
https://review.openstack.org/95356

One of the issues with this patch is that it only handles SCSI attached disks, for which reason this issue continues to occur when having generation 1 VMs booted from volume, in which case the disk will be placed on the IDE controller.

In this case, one instance may end up booting from another tenant's volume, which is a critical security issue.

Also, it assumes that the block device info volume order matches the according disk controller slot order, which is wrong.

Related bug: https://bugs.launchpad.net/nova/+bug/1322926

[Tristan Cacqueray (tristan-cacqueray)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Jeremy Stanley (fungi)]

While this sounds like a very unfortunate bug/flaw, how would a malicious actor cause it to occur in an effort to exploit it? Seems like it would be sheer random occurrence.

[Jeremy Stanley (fungi)]

Also, if it's not something an unprivileged attacker can trigger, I don't see any benefit to keeping this bug embargoed while the fix is developed and reviewed.

[Tristan Cacqueray (tristan-cacqueray)]

I agree, there are no immediate impacts caused by this bug, unless there is way to force compute reboot.

If nobody complains by the end of the year, let's make this report public and raise awareness from hyperV experts.

[Tony Breeds (o-tony)]

I'm going to add the Hyper-V people to this bug. At the very least this gives them a 'heads up' that the bug will be open next year.

Now to work out how to do that thing :)

[Tony Breeds (o-tony)]

My feeling is that we only need to keep this embargoed if an unprivileged user/attacker can a) force the server to reboot and b) control the reassignments.

If the attacker can't do both of those things then it's just a regular bug.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks Tony, I removed the OSSA task

[Alessandro Pilotti (alexpilotti)]

Fix: https://review.openstack.org/#/c/258615/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/258614
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=82bf282dd599d9c1528a34a032513e6721ae9876
Submitter: Jenkins
Branch: master

commit 82bf282dd599d9c1528a34a032513e6721ae9876
Author: Lucian Petrut <email address hidden>
Date: Mon Dec 7 12:09:22 2015 +0200

    HyperV: Set disk serial number for attached volumes

    Setting the disk serial number allows us to easily map volumes
    with the according virtual disk resources.

    This is required for the Fibre Channel support implementation, as
    well for the patch fixing the swapped VM disks after host reboot.

    Co-Authored-By: Alin Balutoiu <email address hidden>

    Partial-Bug: #1526831
    Depends-On: I7faf798aa7c1c306ac641f4364b1407b80b40b09
    Change-Id: I5a91c12eb54d8539e30598e617eb9f036fbba843

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/258615
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9de0bec4f9cdf0cd6424aeb95daabe657d4db2d4
Submitter: Jenkins
Branch: master

commit 9de0bec4f9cdf0cd6424aeb95daabe657d4db2d4
Author: Lucian Petrut <email address hidden>
Date: Thu Dec 10 19:23:08 2015 +0200

    HyperV: Fix vm disk path issue

    As the disk number of iSCSI attached disks can change after host
    reboot, passthrough attached volumes can get attached in this case.

    This bug was partially fixed during Icehouse by this patch:
    https://review.openstack.org/95356

    One of the issues with this patch is that it only handles SCSI
    attached disks, for which reason this issue continues to occur when
    having generation 1 VMs booted from volume, in which case the disk
    will be placed on the IDE controller.

    In this case, one instance may end up booting from another tenant's
    volume, which is a critical security issue.

    Also, it assumes that the block device info volume order matches
    the according disk controller slot order, which is wrong.

    This patch fixes this issue, looping through the block device
    info and fixing the disk path for all the passthrough attached
    disks, regardless of the disk controller.

    This requires the virtual disk resources attached to the instance
    to be tagged with the serial number.

    Co-Authored-By: Alin Balutoiu <email address hidden>

    Closes-Bug: #1526831
    Depends-On: Ibe463ce9ffb9129cab4b99fe7967ccb5f2181958
    Change-Id: Icf8697d917c814ec120fce9898661eb9a20ade48

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/nova 13.0.0.0b3 development milestone.