[OSSA 2013-019] Resource limit circumvention in Nova private flavors (CVE-2013-2256)

[hzrandd]

i want to display the bug as follows:
make sure the role is admin: source devstack/openrc admin admin
i create a private flavor as follows：

nova flavor-create test1 7 512 4 2

make sure the role is demo: source devstack/openrc demo demo

ok,now i use 'nova flavor-list'
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+---------------------------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+---------------------------+
| 3 | m1.medium | 4096 | 40 | 0 | | 2 | 1.0 | True | {u'ecus_per_vcpu:': u'1'} |
| 4 | m1.large | 8192 | 80 | 0 | | 4 | 1.0 | True | {u'ecus_per_vcpu:': u'1'} |
| 5 | m1.xlarge | 16384 | 160 | 0 | | 8 | 1.0 | True | {u'ecus_per_vcpu:': u'1'} |

+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+---------------------------+
but,when i use 'nova flavor-show' :
nova flavor-show 7
+----------------------------+-------+
| Property | Value |
+----------------------------+-------+
| OS-FLV-DISABLED:disabled | False |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 4 |
| extra_specs | {} |
| id | 7 |
| name | test1 |
| os-flavor-access:is_public | False |
| ram | 512 |
| rxtx_factor | 1.0 |
| swap | |
| vcpus | 2 |
+----------------------------+-------+
so,the demo can boot a new instance with the private flavor.i want to prevent other tenants accessing my private flavor, such as the command: nova flavor-show , only on this way can we prevent the other tenants use my private flavors to create instance.

ok,i modfiy the codes in 'nova/api/openstack/compute/flavors.py' to fix this bug.
def show(self, req, id):
    """Return data about the given flavor id."""
    try:

     context = req.environ['nova.context']
     flavor = instance_types.get_instance_type_by_flavor_id(id, context)

     if not context.is_admin:
         flavors = self._get_flavors(req)
         flavor_is_not = False
        for k in flavors:
            if k.get('flavorid', None) != flavor.get('flavorid', None)\
                               and flavor.get('is_public', None) == False:
                flavor_is_not = True
        if flavor_is_not:
            raise webob.exc.HTTPNotFound()
    req.cache_db_flavor(flavor)
    except exception.NotFound:
        raise webob.exc.HTTPNotFound()

    return self._view_builder.show(req, flavor)

[Russell Bryant (russellb)]

I just reproduced this.

I created a non-public flavor as an admin:

    $ . openrc admin
    $ nova flavor-create test2 8 512 4 2 --is-public False

I switched to the regular user and could still see the flavor and start an instance with it. It was not included in "nova flavor-list".

$ . openrc
$ nova flavor-show 8
+----------------------------+-------+
| Property | Value |
+----------------------------+-------+
| name | test2 |
| ram | 512 |
| OS-FLV-DISABLED:disabled | False |
| vcpus | 2 |
| extra_specs | {} |
| swap | |
| os-flavor-access:is_public | False |
| rxtx_factor | 1.0 |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 4 |
| id | 8 |
+----------------------------+-------+
[rbryant@devstack devstack]$ nova flavor-show 7
+----------------------------+-------+
| Property | Value |
+----------------------------+-------+
| name | test1 |
| ram | 512 |
| OS-FLV-DISABLED:disabled | False |
| vcpus | 2 |
| extra_specs | {} |
| swap | |
| os-flavor-access:is_public | True |
| rxtx_factor | 1.0 |
| OS-FLV-EXT-DATA:ephemeral | 0 |
| disk | 4 |
| id | 7 |
+----------------------------+-------+
[rbryant@devstack devstack]$ nova boot --flavor 8 --image e1f736ac-edc3-47b3-864c-2bef7cb08a6b test
+-------------------------------------+--------------------------------------+
| Property | Value |
+-------------------------------------+--------------------------------------+
| OS-EXT-STS:task_state | scheduling |
| image | cirros-0.3.1-x86_64-uec |
| OS-EXT-STS:vm_state | building |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |
| OS-SRV-USG:launched_at | None |
| flavor | test2 |
| id | 66c6c9df-b754-4e4d-8d2b-4062f68865c9 |
| security_groups | [{u'name': u'default'}] |
| user_id | d188cab557114a0ea336b5d3a0c15288 |
| OS-DCF:diskConfig | MANUAL |
| accessIPv4 | |
| accessIPv6 | |
| progress | 0 |
| OS-EXT-STS:power_state | 0 |
| OS-EXT-AZ:availability_zone | nova |
| config_drive | |
| status | BUILD ...

[Russell Bryant (russellb)]

oops, the flavor-show of 7 isn't relevant.

[Russell Bryant (russellb)]

I looked back as far as Essex and it appears broken that far back, as well.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/34963

[Thierry Carrez (ttx)]

I don't think flavor descriptions is a critical info leak (unless I'm missing something), but I agree we should probably issue an OSSA about this. Other thoughts ?

[Jeremy Stanley (fungi)]

I agree on the OSSA, for thoroughness. I can work on impact description and so on tomorrow if it's deemed helpful.

[Russell Bryant (russellb)]

Note that it's not just flavor descriptions. You're also allowed to boot instances using these flavors.

[Russell Bryant (russellb)]

Added tempest, as it looks like some work is needed there before the fix can be merged.

[Russell Bryant (russellb)]

tempest: 1, me: 0

[Jeremy Stanley (fungi)]

hzrandd, as the original reporter of this bug, how would you like to be credited in the advisory? (full name and, if applicable, employer's name as well)

[Jeremy Stanley (fungi)]

Proposed impact description...

Title: Information leak in Nova private flavors
Reporter: hzrandd (NetEase)
Products: Nova
Affects: All versions

hzrandd from NetEase reported an information leak vulnerability in
Nova's handling of private flavors. Any tenant is able to show and
boot any other tenant's private flavors by guessing the flavor ID,
exposing its name, memory and disk size, swap allocation, VCPU count
and similar flavor properties.

(...obviously replacing above with whatever citation hzrandd requests)

[Thierry Carrez (ttx)]

Impact description looks good to me

[Russell Bryant (russellb)]

I think the problem is a little worse than described. It's not just about being able to see the flavor details. The ability to boot it is significant here. It means you're able to boot an instance with a set of resources you were not supposed to have access to. This could result in your instance ending up on hardware you weren't supposed to have access to, as one example. That's a bigger problem than the fact that you can see flavor details to me.

[Jeremy Stanley (fungi)]

Ahh, in that case how's...

Title: Resource limit circumvention in Nova private flavors
Reporter: hzrandd (NetEase)
Products: Nova
Affects: All versions

hzrandd from NetEase reported a resource limit circumvention
vulnerability in Nova's handling of private flavors. Any tenant is
able to show and boot any other tenant's private flavors by guessing
a flavor ID. This not only exposes the flavor's name, memory and
disk size, swap allocation, VCPU count and similar flavor
properties, but potentially allows circumvention of any resource
limits enforced through the os-flavor-access:is_public property.

(...obviously replacing above with whatever citation hzrandd requests)

[Thierry Carrez (ttx)]

Still works for me

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/34963
Committed: http://github.com/openstack/nova/commit/b65d506a5f9d9b2b20777a9aceb44a8ffed6a5de
Submitter: Jenkins
Branch: master

commit b65d506a5f9d9b2b20777a9aceb44a8ffed6a5de
Author: Russell Bryant <email address hidden>
Date: Thu Jun 27 21:00:05 2013 +0000

    Make flavors is_public option actually work

    When you create a flavor, you can set an is_public flag to be True or
    False. It is True by default. When False, the intention is that the
    flavor is only accessible by an admin, unless you use the flavor_access
    API extension to grant access to specific tenants.

    Unfortunately, the only place in the code where this was being enforced
    was when listing flavors through the API. It would filter out the
    non-public ones for a non-admin. Otherwise, the flavor was accessible.
    You could get the details, and you could boot an instance with it, if
    you figured out a valid flavor ID.

    This patch adds enforcement down in the db layer. It also fixes one
    place in the API where the context wasn't passed down to enable the
    enforcement to happen.

    Fix bug 1194093.

    Change-Id: I5b37fa0bb19683fe1642fd81222547d4a317054e

[Thierry Carrez (ttx)]

fungi: I think it's safe to proceed with disclosure warning for stakeholders, just citing "hzrandd" as reporter.

[Thierry Carrez (ttx)]

We need the Folsom/Grizzly backports in before we can make progress here.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/37992

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/folsom
Review: https://review.openstack.org/38318

[Thomas Goirand (thomas-goirand)]

Hi,
I tried to backport the patch to Essex, and it's far from trivial. Is the Canonical security team working on it?

[Ken'ichi Ohmichi (oomichi)]

Hi,

I feel we need to fix this problem for "create an instance" API.
I have reported the other bug ticket(#1212179) and proposed the code(https://review.openstack.org/#/c/41875/) because this ticket is "Fix Released".