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

Bug #1194093 reported by hzrandd on 2013-06-24
266
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Critical
Russell Bryant
Grizzly
Critical
Russell Bryant
OpenStack Security Advisory
High
Jeremy Stanley

Bug Description

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)

Tags: api Edit Tag help
tags: added: api
Russell Bryant (russellb) wrote :
Download full text (4.1 KiB)

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 ...

Read more...

Russell Bryant (russellb) wrote :

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

information type: Public → Public Security
Changed in nova:
status: New → Confirmed
importance: Undecided → Critical
milestone: none → havana-2
Changed in nova:
assignee: nobody → Russell Bryant (russellb)
Russell Bryant (russellb) wrote :

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

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

Changed in nova:
status: Confirmed → In Progress

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 ?

Changed in ossa:
status: New → Incomplete
Jeremy Stanley (fungi) wrote :

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

Changed in ossa:
status: Incomplete → Confirmed
importance: Undecided → Critical
assignee: nobody → Jeremy Stanley (fungi)
Russell Bryant (russellb) wrote :

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

Russell Bryant (russellb) wrote :

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

Russell Bryant (russellb) wrote :

tempest: 1, me: 0

Changed in tempest:
status: New → Invalid
Jeremy Stanley (fungi) wrote :

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) wrote :

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)

Changed in ossa:
status: Confirmed → Triaged
Thierry Carrez (ttx) wrote :

Impact description looks good to me

Changed in ossa:
importance: Critical → Medium
Russell Bryant (russellb) wrote :

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) wrote :

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) wrote :

Still works for me

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

Changed in nova:
status: In Progress → Fix Committed

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

Changed in ossa:
importance: Medium → High
Jeremy Stanley (fungi) on 2013-07-09
Changed in ossa:
status: Triaged → In Progress
Jeremy Stanley (fungi) on 2013-07-09
summary: - Other tenants can access my private flavor.
+ Resource limit circumvention in Nova private flavors (CVE-2013-2256)

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

Thierry Carrez (ttx) on 2013-07-17
Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-08-01
no longer affects: tempest
Jeremy Stanley (fungi) on 2013-08-05
Changed in ossa:
status: In Progress → Fix Committed
Jeremy Stanley (fungi) on 2013-08-06
summary: - Resource limit circumvention in Nova private flavors (CVE-2013-2256)
+ [OSSA 2013-019] Resource limit circumvention in Nova private flavors
+ (CVE-2013-2256)
Jeremy Stanley (fungi) on 2013-08-06
Changed in ossa:
status: Fix Committed → Fix Released

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) wrote :

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".

Thierry Carrez (ttx) on 2013-10-17
Changed in nova:
milestone: havana-2 → 2013.2
Sean Dague (sdague) on 2014-09-19
no longer affects: nova/folsom
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers