Vulnerability in Nova instance resize/migration

Please note that the patches have been updated:

  https://review.openstack.org/289957 (mitaka)
  https://review.openstack.org/289958 (liberty)
  https://review.openstack.org/289960 (kilo)

https://review.openstack.org/#/c/289957/ fix for mitaka merged - marking as Invalid for 9.0

Here is CR for 8.0: https://review.fuel-infra.org/#/c/18749/

Here is CR for 7.0: https://review.fuel-infra.org/#/c/18804/

Abandoned CR for 8.0 https://review.fuel-infra.org/#/c/18749/ because changes from upstream is merged automatically for this branch.

Setting to Invalid for 8.0-updates according to comment #8

CR for 6.1: https://review.fuel-infra.org/#/c/18810/
CR for 6.0: https://review.fuel-infra.org/#/c/18836/

Steps to verify the bug:

Steps to reproduce for 8.0 in case of resizing instance is pretty well described here: https://bugs.launchpad.net/nova/+bug/1548450/comments/7
After applying patch device mount with malicous image should fail.

Steps to reproduce for 7.0 mostly the same as for 8.0, but a bit more complicated since the novaclient in 7.0 doesn't work with ephemeral disk. That's why instead of using novaclient I've launched nova instance with curl request to API:
curl -g -i -X POST http://192.168.0.2:8774/v2/4c8a72cfeea54b7694a2495516aebd4f/os-volumes_boot -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: 4721b11bb0694f92baf6cd9bed12ccc1" -d '{"server": {"name": "test-boot", "imageRef": "89deb937-0022-4a48-97bb-efdf3e5592c7", "key_name": "local", "flavorRef": "6", "max_count": 1, "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "89deb937-0022-4a48-97bb-efdf3e5592c7", "destination_type": "local"}, {"guest_format": "ext4", "boot_index": -1, "volume_size": "1", "source_type": "blank", "destination_type": "local", "delete_on_termination": true}], "min_count": 1, "networks": [{"uuid": "8b0b141f-16e8-4266-a734-c585b8047d88"}]}}'
Of cource you should change URL, keystone token, image ID and network ID in provided curl request before using it.

Notes for 5.1.1 and 6.0:
For some reason I was not able to login via SSH to Fedora 23 instance. That's why I did reproduction of the bug on CentOS 7 image. Also CentOS image requires more disk space in flavor, that's why I had created a bit different flavors for reproducing. Here is the set of command used by me in order to boot CentOS 7 image:

wget http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2
glance image-create --name centos --file CentOS-7-x86_64-GenericCloud.qcow2 --disk-format qcow2 --container-format bare --progress
nova flavor-create eph 6 1024 15 1 --ephemeral 1
nova flavor-create eph_large 7 2048 15 1 --ephemeral 1
nova boot --key-name local --image centos --ephemeral size=1,format=ext4 --flavor eph --nic net-id=43c69cda-f093-439e-b96e-64629b76f8b5 test-boot

Reviewed: https://review.fuel-infra.org/18836
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-ci/fuel-6.0-updates/2014.2

Commit: 08b91be0eef7e8bc067849d5999ff69d59383fc6
Author: Lee Yarwood <email address hidden>
Date: Wed Apr 13 13:15:13 2016

libvirt: Always copy or recreate disk.info during a migration

The disk.info file contains the path and format of any image, config or
ephermal disk associated with an instance. When using RAW images and migrating
an instance this file should always be copied or recreated. This avoids the Raw
imagebackend reinspecting the format of these disks when spawning the instance
on the destination host.

By not copying or recreating this disk.info file, a malicious image written to
an instance disk on the source host will cause Nova to reinspect and record a
different format for the disk on the destination. This format then being used
incorrectly when finally spawning the instance on the destination.

Fix processing of libvirt disk.info in non-disk-image cases

In Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 (upstream) a change was made
that caused non-disk-image backends to fall over because of an
undefined variable because they skipped processing of the disk.info
file. This adds a check for that case to make sure we don't run
that path in the non-disk-image backend case.

libvirt: Decode disk_info before use

The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that
disk_info is always a plain, decoded list. However prior to Liberty
when preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
self.driver.get_instance_disk_info. In the live migration case without
block migration disk_info is None.

As a result we should always decode disk_info when a block migration
is called for to ensure that we can iterate over the disks and rebuild
the disk.info file.

The following change removed the JSON encoding from
get_instance_disk_info and other methods within the libvirt driver for
Liberty.

libvirt: Remove unnecessary JSON conversions
https://review.openstack.org/#/c/177437/6

SecurityImpact
Closes-bug: #1552683
Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87

Reviewed: https://review.fuel-infra.org/18804
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-ci/fuel-7.0/2015.1.0

Commit: ae65990b01462e7282845ace3ea3ec6adb02c696
Author: Lee Yarwood <email address hidden>
Date: Wed Apr 13 12:53:24 2016

libvirt: Always copy or recreate disk.info during a migration

The disk.info file contains the path and format of any image, config or
ephermal disk associated with an instance. When using RAW images and migrating
an instance this file should always be copied or recreated. This avoids the Raw
imagebackend reinspecting the format of these disks when spawning the instance
on the destination host.

By not copying or recreating this disk.info file, a malicious image written to
an instance disk on the source host will cause Nova to reinspect and record a
different format for the disk on the destination. This format then being used
incorrectly when finally spawning the instance on the destination.

Fix processing of libvirt disk.info in non-disk-image cases

In Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 (upstream) a change was made
that caused non-disk-image backends to fall over because of an
undefined variable because they skipped processing of the disk.info
file. This adds a check for that case to make sure we don't run
that path in the non-disk-image backend case.

libvirt: Decode disk_info before use

The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that
disk_info is always a plain, decoded list. However prior to Liberty
when preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
self.driver.get_instance_disk_info. In the live migration case without
block migration disk_info is None.

As a result we should always decode disk_info when a block migration
is called for to ensure that we can iterate over the disks and rebuild
the disk.info file.

The following change removed the JSON encoding from
get_instance_disk_info and other methods within the libvirt driver for
Liberty.

libvirt: Remove unnecessary JSON conversions
https://review.openstack.org/#/c/177437/6

SecurityImpact
Closes-bug: #1552683
Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87

Reviewed: https://review.fuel-infra.org/18810
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-ci/fuel-6.1/2014.2

Commit: 2c7688964716c4cf20a18c88a10c7d2e00bc5210
Author: Lee Yarwood <email address hidden>
Date: Wed Apr 13 12:52:45 2016

libvirt: Always copy or recreate disk.info during a migration

The disk.info file contains the path and format of any image, config or
ephermal disk associated with an instance. When using RAW images and migrating
an instance this file should always be copied or recreated. This avoids the Raw
imagebackend reinspecting the format of these disks when spawning the instance
on the destination host.

By not copying or recreating this disk.info file, a malicious image written to
an instance disk on the source host will cause Nova to reinspect and record a
different format for the disk on the destination. This format then being used
incorrectly when finally spawning the instance on the destination.

Fix processing of libvirt disk.info in non-disk-image cases

In Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 (upstream) a change was made
that caused non-disk-image backends to fall over because of an
undefined variable because they skipped processing of the disk.info
file. This adds a check for that case to make sure we don't run
that path in the non-disk-image backend case.

libvirt: Decode disk_info before use

The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that
disk_info is always a plain, decoded list. However prior to Liberty
when preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
self.driver.get_instance_disk_info. In the live migration case without
block migration disk_info is None.

As a result we should always decode disk_info when a block migration
is called for to ensure that we can iterate over the disks and rebuild
the disk.info file.

The following change removed the JSON encoding from
get_instance_disk_info and other methods within the libvirt driver for
Liberty.

libvirt: Remove unnecessary JSON conversions
https://review.openstack.org/#/c/177437/6

SecurityImpact
Closes-bug: #1552683
Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87

Reproduced on mos6.1
Verified on mos6.1+mu6 updates

Used scenario described in https://bugs.launchpad.net/nova/+bug/1548450/comments/7

Reviewed: https://review.fuel-infra.org/18868
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-ci/fuel-5.1.1-updates/2014.1.1

Commit: 311f0e8bc162819988d347c1b32b76266c3ee7c9
Author: Lee Yarwood <email address hidden>
Date: Thu May 19 15:30:07 2016

libvirt: Always copy or recreate disk.info during a migration

The disk.info file contains the path and format of any image, config or
ephermal disk associated with an instance. When using RAW images and migrating
an instance this file should always be copied or recreated. This avoids the Raw
imagebackend reinspecting the format of these disks when spawning the instance
on the destination host.

By not copying or recreating this disk.info file, a malicious image written to
an instance disk on the source host will cause Nova to reinspect and record a
different format for the disk on the destination. This format then being used
incorrectly when finally spawning the instance on the destination.

Fix processing of libvirt disk.info in non-disk-image cases

In Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 (upstream) a change was made
that caused non-disk-image backends to fall over because of an
undefined variable because they skipped processing of the disk.info
file. This adds a check for that case to make sure we don't run
that path in the non-disk-image backend case.

libvirt: Decode disk_info before use

The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that
disk_info is always a plain, decoded list. However prior to Liberty
when preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
self.driver.get_instance_disk_info. In the live migration case without
block migration disk_info is None.

As a result we should always decode disk_info when a block migration
is called for to ensure that we can iterate over the disks and rebuild
the disk.info file.

The following change removed the JSON encoding from
get_instance_disk_info and other methods within the libvirt driver for
Liberty.

libvirt: Remove unnecessary JSON conversions
https://review.openstack.org/#/c/177437/6

SecurityImpact
Closes-bug: #1552683
Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87