os-assisted-volume-snapshots passes unsanitised file path to the libvirt driver
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Confirmed
|
Medium
|
Lee Yarwood | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Nova’s os-assisted-
I have not been able to exploit this for a few reasons. Most significantly, by default this api is restricted by policy to be admin only, and there are simpler avenues available to admin to destroy user data. Also, for create the destination path must already exist and be in qcow2 format, and for delete the destination path must (N.B. a libvirt expert should verify this assertion for me) be in the existing backing chain of the volume. I believe this is likely to make delete safe, with only create being potentially exploitable.
For create, the user can call guest.snapshot with the snapshot path containing any path on the host:
I have verified this on devstack with the following:
$ cat snapshot.json
{
"snapshot": {
"type": "qcow2",
}
}
}
$ curl -i -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" -d "$(cat snapshot.json)" http://
In this case the referenced volume was iscsi and therefore had a path of /dev/sda. The resulting snapshot location was therefore /dev/..
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none' io='native'/>
<source file='/
<backingStore type='block' index='1'>
<format type='raw'/>
<source dev='/dev/sda'/>
<
<target dev='vdb' bus='virtio'/>
<
<alias name='virtio-
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
I believe the potential exploit is to be able to overwrite a qcow2 formatted file anywhere on the host with arbitrary data. The attacker would also have to know the location of this path. Block devices have trivially guessable paths, but these are not likely to contain a qcow2 header. In practise the most likely target would be local qcow2 disks, but this would also require knowing an instance uuid. And, without any other exploit, the user would need to be admin.
Although I was not able to exploit this myself, this is a poorly defined interface which seems generally vulnerable to either somebody more inventive than me, or future seemingly innocuous code changes or bugs. I suspect that more conservative users in particular would prefer not to expose this capability at all via a REST api, especially if they aren’t using it because they don’t use cinder remotefs, or they don’t use volume snapshots. I recommend:
* In the absence of any likely exploit, we open this bug immediately.
* We try to apply some practical sanitisation to the API-definable paths.
* We provide a mechanism to disable this API for users who don't need it.
* We attempt to replace it with a safer API in a future release.
tags: | added: snapshot volumes |
description: | updated |
Changed in nova: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in nova: | |
assignee: | nobody → Lee Yarwood (lyarwood) |
I've added Sean and Lee for some additional eyes on it in case we can create an exploit.