[OSSA 2013-033] Metadata queries from Neutron to Nova are not restricted by tenant (CVE-2013-6419)

Bug #1235450 reported by Aaron Rosen on 2013-10-04
278
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
High
Aaron Rosen
Grizzly
High
Aaron Rosen
Havana
High
Aaron Rosen
OpenStack Security Advisory
High
Jeremy Stanley
neutron
Critical
Aaron Rosen
Grizzly
Critical
Aaron Rosen
Havana
Critical
Aaron Rosen

Bug Description

The neutron metadata service works in the following way:

Instance makes a GET request to http://169.254.169.254/

This is directed to the metadata-agent which knows which router(namespace) he is running on and determines the ip_address from the http request he receives.

Now, the neturon-metadata-agent queries neutron-server using the router_id and ip_address from the request to determine the port the request came from. Next, the agent takes the device_id (nova-instance-id) on the port and passes that to nova as X-Instance-ID.

The vulnerability is that if someone exposes their instance_id their metadata can be retrieved. In order to exploit this, one would need to update the device_id on a port to match the instance_id they want to hijack the data from.

To demonstrate:

arosen@arosen-desktop:~/devstack$ nova list
+--------------------------------------+------+--------+------------+-------------+------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+------+--------+------------+-------------+------------------+
| 1eb33bf1-6400-483a-9747-e19168b68933 | vm1 | ACTIVE | None | Running | private=10.0.0.4 |
| eed973e2-58ea-42c4-858d-582ff6ac3a51 | vm2 | ACTIVE | None | Running | private=10.0.0.3 |
+--------------------------------------+------+--------+------------+-------------+------------------+

arosen@arosen-desktop:~/devstack$ neutron port-list
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+
| id | name | mac_address | fixed_ips |
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+
| 3128f195-c41b-4160-9a42-40e024771323 | | fa:16:3e:7d:a5:df | {"subnet_id": "d5cbaa98-ecf0-495c-b009-b5ea6160259b", "ip_address": "10.0.0.1"} |
| 62465157-8494-4fb7-bdce-2b8697f03c12 | | fa:16:3e:94:62:47 | {"subnet_id": "d5cbaa98-ecf0-495c-b009-b5ea6160259b", "ip_address": "10.0.0.4"} |
| 8473fb8d-b649-4281-b03a-06febf61b400 | | fa:16:3e:4f:a3:b0 | {"subnet_id": "d5cbaa98-ecf0-495c-b009-b5ea6160259b", "ip_address": "10.0.0.2"} |
| 92c42c1a-efb0-46a6-89eb-a38ae170d76d | | fa:16:3e:de:9a:39 | {"subnet_id": "d5cbaa98-ecf0-495c-b009-b5ea6160259b", "ip_address": "10.0.0.3"} |
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------+

arosen@arosen-desktop:~/devstack$ neutron port-show 62465157-8494-4fb7-bdce-2b8697f03c12
+-----------------------+---------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+---------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| device_id | 1eb33bf1-6400-483a-9747-e19168b68933 |
| device_owner | compute:None |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "d5cbaa98-ecf0-495c-b009-b5ea6160259b", "ip_address": "10.0.0.4"} |
| id | 62465157-8494-4fb7-bdce-2b8697f03c12 |
| mac_address | fa:16:3e:94:62:47 |
| name | |
| network_id | 5f68c45d-b729-4e21-9ded-089848eb4ef2 |
| security_groups | 3e29d8e7-0195-4438-a49a-9706736b888d |
| status | ACTIVE |
| tenant_id | 0f9d696fc73d4110ab492ca105881b9b |
+-----------------------+---------------------------------------------------------------------------------+

arosen@arosen-desktop:~/devstack$ neutron port-show 92c42c1a-efb0-46a6-89eb-a38ae170d76d
+-----------------------+---------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+---------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | |
| device_id | eed973e2-58ea-42c4-858d-582ff6ac3a51 |
| device_owner | compute:None |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "d5cbaa98-ecf0-495c-b009-b5ea6160259b", "ip_address": "10.0.0.3"} |
| id | 92c42c1a-efb0-46a6-89eb-a38ae170d76d |
| mac_address | fa:16:3e:de:9a:39 |
| name | |
| network_id | 5f68c45d-b729-4e21-9ded-089848eb4ef2 |
| security_groups | 3e29d8e7-0195-4438-a49a-9706736b888d |
| status | ACTIVE |
| tenant_id | 0f9d696fc73d4110ab492ca105881b9b |
+-----------------------+---------------------------------------------------------------------------------+

From vm2 (eed973e2-58ea-42c4-858d-582ff6ac3a51):
$ curl http://169.254.169.254/latest/meta-data/hostname
vm2.novalocal

arosen@arosen-desktop:~/devstack$ neutron port-update 92c42c1a-efb0-46a6-89eb-a38ae170d76d --device_id=1eb33bf1-6400-483a-9747-e19168b68933

 From vm2 (eed973e2-58ea-42c4-858d-582ff6ac3a51):
$ curl http://169.254.169.254/latest/meta-data/hostname
vm1.novalocal

In order to fix this issue I believe we need to also pass the tenant-id in the metadata request to nova. When nova receives the request it will now have to query it's database using the instance_id and check that the tenant_id's match. Using the tenant_id solves this issue as the user is not allowed to specify or update this field.

CVE References

Changed in neutron:
status: New → Confirmed
Aaron Rosen (arosen) wrote :

FYI This affects: Grizzly and Havana.

Aaron Rosen (arosen) wrote :

Also, passing in the tenant-id as well does not enforce a tenant from spoofing themselves but i think this is okay.

An extra layer of security would be to make the device opaque by encrypting it using the tenant id of the port owner. To steal the data now, we not only need to compromise the agent, but also the neutron server.

Mark McClain (markmcclain) wrote :

I can confirm that cross tenant metadata leaks are possible. The exploit requires that the instance_id be obtained or that a valid UUID is randomly guessed correctly. This will need to be fixed in Grizzly stable and the Havana RC and we've got a team to discuss and work on a fix.

Thierry Carrez (ttx) wrote :

IIUC the fix requires both changing Nova and Neutron ? Or is there a way to fix this that would only involve one party ? (that would make it easier to publish as a security fix)

Changed in ossa:
importance: Undecided → High
status: New → Confirmed
Aaron Rosen (arosen) wrote :

 unfortunately a change is needed in both. One in neutron to pass the tenant-id in the request as well and one in nova to ensure that the tenant-id matches the instance-id.

Aaron Rosen (arosen) wrote :

Fix for nova see attached.

Aaron Rosen (arosen) wrote :

Whoops left of the Fixes bug: 1235450 on last patch. Review attached patch instead.

Changed in nova:
assignee: nobody → Aaron Rosen (arosen)
status: New → Confirmed
importance: Undecided → High

testing the patches...a suggestion would be for the nova patch to add a test to verify that a 404 gets returned if the project id for the instance does not match the tenant id specified in the header, in order to avoid potential regressions. I don't seem to find this kind of test. However I'd be fine to see this as a follow up patch once the security vulnerability is addressed. What do you think?

Thierry Carrez (ttx) wrote :

@Russell: could you get some Nova reviewers on the Nova portion of that patch ?

Aaron Rosen (arosen) wrote :

@Armando - thanks for reviewing. There is such test already:

+ # mismatched X-Tenant-ID
+ response = fake_request(
+ self.stubs, self.mdinst,
+ relpath="/2009-04-04/user-data",
+ address="192.192.192.2",
+ fake_get_metadata_by_instance_id=fake_get_metadata,
+ headers={'X-Forwarded-For': '192.192.192.2',
+ 'X-Instance-ID': 'a-b-c-d',
+ 'X-Tenant-ID': 'FAKE',
+ 'X-Instance-ID-Signature': signed})
+
+ self.assertEqual(response.status_int, 404)

Thanks for pointing that out, I didn't notice there was one giant test case, yuk :)

Aaron Rosen (arosen) wrote :

Yea I agree. But I didn't want to refactor the existing tests in a sec vul patch.

The two patches are okay from what I can tell. Are you gonna post grizzly ones too?

Aaron Rosen (arosen) wrote :

@Armando sure i'll do that now. I was hoping to get review concense on my first two patches first. Coming right up

Aaron Rosen (arosen) wrote :
Aaron Rosen (arosen) wrote :
Aaron Rosen (arosen) wrote :

It would be great if we could get these matches in especially before the final RC of neturon and nova.

Jeremy Stanley (fungi) wrote :

I agree--it would be lovely if some nova and neutron core reviewers could give these patches a once-over (and +2 them if appropriate). The sooner we can get this fixed and an advisory released, the better.

Thierry Carrez (ttx) wrote :

Given the embargo rules (4 business days of pre-disclosure) it's now impossible for us to fix this before release. I'd like to issue the advisory for it soon after release though, so reviewing would be nice.

Russell Bryant (russellb) wrote :

Nova patch comments:

1) Since this is going into stable, do you think we should make it handle the case of a missing X-Tenant-ID header not fail the request?

2)

+ elif not isinstance(tenant_id, basestring):
+ msg = _('Multiple X-Tenant-ID headers found within request.')

Would checking if tenant_id is a list be a more explicit check for the msg you are assigning to it? I see that it's just a copy of the handling for another header, so I guess it's fine to just leave it as-is.

Otherwise, patch seems fine to me. Thanks!

Dan Smith (danms) wrote :

+2 from me on the patch as it is. I think the new change in expected client behavior (the new header) is better than the alternative of the spoofing risk.

Russell Bryant (russellb) wrote :

Ok, that works for me. +2 on the nova patch

Thanks!

Mark McClain (markmcclain) wrote :

We need to wait a bit longer before disclosing this patch so that we can investigate a possible related issue.

Thierry Carrez (ttx) wrote :

@MarkMcClain: any progress there ?

Aaron Rosen (arosen) wrote :

Hi Thierry - MarkMcClain pointed out there is another instance where this occurs: https://bugs.launchpad.net/neutron/+bug/1243327 I think all of these patches should go in at the same thing perhaps.

Thierry Carrez (ttx) wrote :

It's a bit unclear to me how the two issues are directly related, so I can't answer if a single patch makes more sesne than two separate patches here. Could one of you enlighten me ?

Aaron Rosen (arosen) wrote :

Hi Thierry,

Yes they are two separate issues both allowing the vulnerability to occur by the tenant changing the device_id. These should be fixed in different patches. I'll ping a new neutron cores and get them to review the other bug report and hopefully we can proceed forward with getting this fixed.

Thierry Carrez (ttx) wrote :

Cool, please attach patches to this bug for private review

Thierry Carrez (ttx) wrote :

@arosen, @markmcclain: is anybody working on a patch for this ?

Aaron has been waiting for reviews besides mine.

and the others...but furthermore we wonder how to get this stuff to merge without going through the usual workflow.

Thierry Carrez (ttx) wrote :

@Armando: we idea is to gather the necessary approvals for the patch on this bug (two core people saying +2). Then when the issue is made public we can propose it for review and get a single core reviewer to +2/APRV it based on the approvals collected on the bug. That way we can reduce the window where the vulnerability is public but no advisory has been published.

For more information on our workflow, see https://wiki.openstack.org/wiki/VulnerabilityManagement

Akihiro Motoki (amotoki) wrote :

Sorry for the late chime in.
I reviewed and tested the patches for master and grizzly branch.

(Neutron patches) +2 for both branches
(Nova pathces) Looks good (+1), but we need to rebase the patch to master branch.

Jeremy Stanley (fungi) wrote :

Okay, so we have 2x +2 (Russell and Dan) on nova-patch-master.txt and nova-grizzly-patch.txt, and 2x +2 (Armando and Akihiro) on neutron-patch-master.txt and neutron-grizzly-patch.txt.

Are nova-patch-master.txt and neutron-patch-master.txt also expected to work as-is on stable/havana branches now?

We still need stable (Grizzly and Havana) bugtasks added to this bug for both Neutron and Nova.

Thierry Carrez (ttx) wrote :

yay series

Aaron Rosen (arosen) wrote :

These patches don't apply on master right now. I'm rebasing and retesting. I'll upload a rebased set shortly.

Aaron Rosen (arosen) wrote :
Aaron Rosen (arosen) wrote :
Aaron Rosen (arosen) wrote :

The same patches in comment 7/9 are good for icehouse.

tags: added: metadata
Jeremy Stanley (fungi) on 2013-11-25
Changed in ossa:
assignee: nobody → Jeremy Stanley (fungi)
Jeremy Stanley (fungi) wrote :

Proposed impact description
--
Title: Router metadata queries are not restricted by tenant
Reporter: Aaron Rosen (VMware)
Products: Neutron
Affects: All supported releases

Description:
Aaron Rosen from VMware reported a vulnerability in OpenStack Neutron. By guessing the instance_id or UUID of a tenant's router, another tenant may retrieve its metadata resulting in potential information disclosure. Only OpenStack setups running Neutron are affected.
--
I can't help but feel this is a little light on details. Anyone have any improvements to suggest before I request a CVE?

Grant Murphy (gmurphy) wrote :

My only comment is that I wouldn't necessarily say 'guessing the instance_id or UUID'. Guessing a UUID is (in theory) pretty difficult. In my mind the premise of this attack is essentially an insecure direct object reference. i.e. An authorization check was not in place to ensure that instance_id has access restricted to a particular tenant_id. So you could potentially rephrase things to focus on that. Although I'm not sure how to rephrase that without going 'off template'.

That's my two cents anyway. Feel free to disregard. After-all I'm new at this :-)

Aaron Rosen (arosen) wrote :

Hi Jeremy, how about this:

--
Title: Metadata queries between neutron and nova are not restricted by tenant
Reporter: Aaron Rosen (VMware)
Products: Neutron / Nova
Affects: All supported releases

Description:
Aaron Rosen from VMware reported a vulnerability in the metadata access between neutron and nova . By guessing the instance_id, another tenant may retrieve its metadata resulting in potential information disclosure. Only OpenStack setups running the neturon-metadata-agent/quantum-metadata-agent are affected.
--

Thierry Carrez (ttx) wrote :

FWIW the template is not a hard rule, it's just a way to achieve common style from different authors :)

Grant Murphy (gmurphy) wrote :

Ok good to know. Also what Aaron said LGTM.

Jeremy Stanley (fungi) wrote :

Revised impact description (thanks Aaron and Grant!)
--
Title: Router metadata queries are not restricted by tenant
Reporter: Aaron Rosen (VMware)
Products: Neutron, Nova
Affects: All supported releases

Description:
Aaron Rosen from VMware reported a vulnerability in the metadata access from OpenStack Neutron to Nova. Because of a missing authorization check on port binding, by guessing the instance_id of a tenant's router another tenant may retrieve its metadata resulting in information disclosure. Only OpenStack setups running neturon-metadata-agent or quantum-metadata-agent are affected.

Aaron Rosen (arosen) wrote :

Hi Jeremy,

The router_id actually doesn't come into play here. The issue is if another tenant finds out another tenants instance_id they can retrieve that instance's metadata. I'd go with the title/description in comment 44

Jeremy Stanley (fungi) wrote :

Ahh, got it. I didn't realize each tenant had only one distinct Nova instance_id and assumed that was per server (or router, a Neutron router is really just a Nova managed server right?). Presumably the requirement of binding the target instance_id to a port as mentioned in the bug description is still valid for this issue? I also get the impression that Neutron queries Nova for metadata but Nova does not query Neutron, correct? Another try...
--------

Title: Metadata queries from Neutron to Nova are not restricted by tenant
Reporter: Aaron Rosen (VMware)
Products: Neutron, Nova
Affects: All supported releases

Description:
Aaron Rosen from VMware reported a vulnerability in the metadata access from OpenStack Neutron to Nova. Because of a missing authorization check on port binding, by guessing an instance_id a tenant may retrieve another tenant's metadata resulting in information disclosure. Only OpenStack setups running neturon-metadata-agent or quantum-metadata-agent are affected.

Thierry Carrez (ttx) wrote :

neturon -> neutron, otherwise looks good (not sure >i'd go and mention quantum-metadata-agent, but meh)

Aaron Rosen (arosen) wrote :

Hi Jeremy,

Nope a neturon router is actually not something that nova manages.

Here's the whole history to this bug. Back in Folsom times or (if using nova-network) the way that metadata works is that nova would look at the source address from the http get request to 169.254.169.254. Since neutron allows you to have overlapping ip_addresses using the source_ip address would no longer work because that was no longer unique. To fix this issue the neutron-metadata-agent was created. This agent intercepts requests to the metadata server at the neutron router. Since we do not allow overlapping ip addresses to be attached to the same router we are able to determine which port made the metadata request. When a metadata request comes in the neutron metadata agent would query neutron (using the source_ip) for the port's device_id(which matches the nova-instance-id) and inserted that as the X-Instance-ID in the metadata request to nova.

Since the device_id on a neutron port is update-able as a tenant, a tenant can change the device_id on his port to any instance_id to extract that instances metadata. The patches attached fix this issue by also passing the tenant_id in the metadata request. This is something that the tenant is not able to change. Then the tenant_id is also check on the nova side to make sure that they match. This ensures that one cannot get around this by spoofing.

Jeremy Stanley (fungi) wrote :

Great explanation--thanks Aaron! With your and Thierry's suggestions, I'll request a CVE with the following impact description unless anyone has further corrections...
--------

Title: Metadata queries from Neutron to Nova are not restricted by tenant
Reporter: Aaron Rosen (VMware)
Products: Neutron, Nova
Affects: All supported releases

Description:
Aaron Rosen from VMware reported a vulnerability in the metadata access from OpenStack Neutron to Nova. Because of a missing authorization check on port binding, by guessing an instance_id a tenant may retrieve another tenant's metadata resulting in information disclosure. Only OpenStack setups running neutron-metadata-agent are affected.

Aaron Rosen (arosen) wrote :

LGTM. Thanks Jeremy!

Mark McClain (markmcclain) wrote :

@fungi +1

Akihiro Motoki (amotoki) wrote :

+1 to The proposed description form Jeremy.

yong sheng gong (gongysh) wrote :

why not put them into the review system for reviewing?

yong sheng gong (gongysh) wrote :

the problem is that the user can change 'device-id', how about disabling to update the device-id once upon the device-id is assigned value?

with the solution:
In order to fix this issue I believe we need to also pass the tenant-id in the metadata request to nova. When nova receives the request it will now have to query it's database using the instance_id and check that the tenant_id's match. Using the tenant_id solves this issue as the user is not allowed to specify or update this field.
one user can still steal all the instance's metadata belong to the same tenant.

Akihiro Motoki (amotoki) wrote :

@gongysh
This bug is a security fix and is not disclosed to all. It is the reason the normal review process (with gerrit) is not used.

Akihiro Motoki (amotoki) wrote :

the solution "update the device-id once upon the device-id is assigned value?" does not fix this issue. A tenant can create a port with device_id of an instance id of another tenant and this vulnerability happens for such case.

Jeremy Stanley (fungi) on 2013-12-02
Changed in ossa:
status: Confirmed → In Progress
Aaron Rosen (arosen) wrote :

@yong - right a tenant can steal his own metadata from his own instances we are aware of that.

yong sheng gong (gongysh) wrote :

with the help of unique device_id?

Jeremy Stanley (fungi) on 2013-12-02
summary: - Metadata is unsecure
+ Metadata is unsecure (CVE-2013-6419)
Jeremy Stanley (fungi) on 2013-12-06
Changed in ossa:
status: In Progress → Fix Committed

Scheduled advisory publication date is Wednesday, December 11, 2013 at 1500UTC (so as to fall before the 2013.2.1 point release). Patches will be pushed to review.openstack.org for last-minute approval shortly prior to that time.

Jeremy Stanley (fungi) wrote :

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

information type: Private Security → Public Security
Changed in nova:
status: Confirmed → In Progress

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

Changed in neutron:
assignee: Aaron Rosen (arosen) → Jeremy Stanley (fungi)
status: Confirmed → In Progress
Jeremy Stanley (fungi) on 2013-12-11
Changed in neutron:
assignee: Jeremy Stanley (fungi) → nobody
Jeremy Stanley (fungi) on 2013-12-11
summary: - Metadata is unsecure (CVE-2013-6419)
+ [OSSA 2013-033] Metadata queries from Neutron to Nova are not restricted
+ by tenant (CVE-2013-6419)
Aaron Rosen (arosen) on 2013-12-11
Changed in neutron:
assignee: nobody → Aaron Rosen (arosen)

Reviewed: https://review.openstack.org/61439
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bd4a85d67f091382752d75b95f9cfd076431f30e
Submitter: Jenkins
Branch: master

commit bd4a85d67f091382752d75b95f9cfd076431f30e
Author: Aaron Rosen <email address hidden>
Date: Mon Oct 7 15:34:38 2013 -0700

    Add X-Tenant-ID to metadata request

    Previously, one could update a port's device_id to be that of
    another tenant's instance_id and then be able to retrieve that
    instance's metadata. In order to prevent this X-Tenant-ID is now
    passed in the metadata request to nova and nova then checks that
    X-Tenant-ID also matches the tenant_id for the instance against it's
    database to ensure it's not being spoofed.

    DocImpact - When upgrading OpenStack nova and neturon, neutron
                should be updated first (and neutron-metadata-agent
                restarted before nova is upgraded) in order to minimize
                downtime. This is because there is also a patch to nova
                which has checks X-Tenant-ID against it's database
                therefore neutron-metadata-agent needs to pass that
                before nova is upgraded for metadata to work.

    Change-Id: I2b8fa2f561a7f2914608e68133abf15efa95015a
    Closes-Bug: #1235450

Changed in neutron:
status: In Progress → Fix Committed

Reviewed: https://review.openstack.org/61442
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=954efa91f08ec1782d41a043584334fcf01a64cb
Submitter: Jenkins
Branch: stable/havana

commit 954efa91f08ec1782d41a043584334fcf01a64cb
Author: Aaron Rosen <email address hidden>
Date: Mon Oct 7 15:34:38 2013 -0700

    Add X-Tenant-ID to metadata request

    Previously, one could update a port's device_id to be that of
    another tenant's instance_id and then be able to retrieve that
    instance's metadata. In order to prevent this X-Tenant-ID is now
    passed in the metadata request to nova and nova then checks that
    X-Tenant-ID also matches the tenant_id for the instance against it's
    database to ensure it's not being spoofed.

    DocImpact - When upgrading OpenStack nova and neturon, neutron
                should be updated first (and neutron-metadata-agent
                restarted before nova is upgraded) in order to minimize
                downtime. This is because there is also a patch to nova
                which has checks X-Tenant-ID against it's database
                therefore neutron-metadata-agent needs to pass that
                before nova is upgraded for metadata to work.

    Change-Id: I2b8fa2f561a7f2914608e68133abf15efa95015a
    Closes-Bug: #1235450

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

commit bce36e9bdb1fcb9658f7b684d160e656e88d816c
Author: Aaron Rosen <email address hidden>
Date: Mon Oct 7 13:33:31 2013 -0700

    Prevent spoofing instance_id from neutron to nova

    Previously, one could update a port's device_id in neutron to be
    that of another tenant's instance_id and then be able to retrieve
    that instance's metadata. This patch prevents this from occurring by
    checking that X-Tenant-ID received from the metadata request matches
    the tenant_id in the nova database.

    DocImpact - This patch is dependent on another patch in neutron
                which adds X-Tenant-ID to the request. Therefore to
                minimize downtime one should upgrade Neutron first (then
                restart neutron-metadata-agent) and lastly update nova.

    Change-Id: I93bf662797c3986324ca2099b403833c2e990fb4
    Closes-Bug: #1235450

Changed in nova:
status: In Progress → Fix Committed

Reviewed: https://review.openstack.org/61435
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=af2f823107010933ecd94a9c938f8b739baaecb7
Submitter: Jenkins
Branch: stable/havana

commit af2f823107010933ecd94a9c938f8b739baaecb7
Author: Aaron Rosen <email address hidden>
Date: Mon Oct 7 13:33:31 2013 -0700

    Prevent spoofing instance_id from neutron to nova

    Previously, one could update a port's device_id in neutron to be
    that of another tenant's instance_id and then be able to retrieve
    that instance's metadata. This patch prevents this from occurring by
    checking that X-Tenant-ID received from the metadata request matches
    the tenant_id in the nova database.

    DocImpact - This patch is dependent on another patch in neutron
                which adds X-Tenant-ID to the request. Therefore to
                minimize downtime one should upgrade Neutron first (then
                restart neutron-metadata-agent) and lastly update nova.

    Change-Id: I93bf662797c3986324ca2099b403833c2e990fb4
    Closes-Bug: #1235450

Reviewed: https://review.openstack.org/61443
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=67d7d9d617c64f41bb899c4ce525a66c84ccf071
Submitter: Jenkins
Branch: stable/grizzly

commit 67d7d9d617c64f41bb899c4ce525a66c84ccf071
Author: Aaron Rosen <email address hidden>
Date: Mon Oct 7 15:34:38 2013 -0700

    Add X-Tenant-ID to metadata request

    Previously, one could update a port's device_id to be that of
    another tenant's instance_id and then be able to retrieve that
    instance's metadata. In order to prevent this X-Tenant-ID is now
    passed in the metadata request to nova and nova then checks that
    X-Tenant-ID also matches the tenant_id for the instance against it's
    database to ensure it's not being spoofed.

    DocImpact - When upgrading OpenStack nova and neturon, neutron
                should be updated first (and neutron-metadata-agent
                restarted before nova is upgraded) in order to minimize
                downtime. This is because there is also a patch to nova
                which has checks X-Tenant-ID against it's database
                therefore neutron-metadata-agent needs to pass that
                before nova is upgraded for metadata to work.

    Change-Id: I2b8fa2f561a7f2914608e68133abf15efa95015a
    Closes-Bug: #1235450

Reviewed: https://review.openstack.org/61437
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=07006be9165d1008ca0382b6f0ad25b13a676a55
Submitter: Jenkins
Branch: stable/grizzly

commit 07006be9165d1008ca0382b6f0ad25b13a676a55
Author: Aaron Rosen <email address hidden>
Date: Mon Oct 7 13:33:31 2013 -0700

    Prevent spoofing instance_id from neutron to nova

    Previously, one could update a port's device_id in neutron to be
    that of another tenant's instance_id and then be able to retrieve
    that instance's metadata. This patch prevents this from occurring by
    checking that X-Tenant-ID received from the metadata request matches
    the tenant_id in the nova database.

    DocImpact - This patch is dependent on another patch in neutron
                which adds X-Tenant-ID to the request. Therefore to
                minimize downtime one should upgrade Neutron first (then
                restart neutron-metadata-agent) and lastly update nova.

    Change-Id: I93bf662797c3986324ca2099b403833c2e990fb4
    Closes-Bug: #1235450

Jeremy Stanley (fungi) on 2013-12-17
Changed in ossa:
status: Fix Committed → Fix Released
Changed in nova:
milestone: none → icehouse-2

Hi,
I have created the common image cache code that can be used by all of the drivers - https://review.openstack.org/#/c/59994/. I need to update the aging patch for the vmware driver to make use of this common code. This should unblock the –2 that you have on the patch (https://review.openstack.org/#/c/56416/). If not can you please let me know why. Hopefully once I get the initial aging done we can start to work on additional algorithms. I am still waiting for inputs form Alvaro (I do not think that advanced aging algorithms should block the basic stuff)
Wishing you and yours a merry xmas and a happy new year
Thanks
Gary

Thierry Carrez (ttx) on 2014-01-22
Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2014-01-22
Changed in neutron:
milestone: none → icehouse-2
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2014-04-17
Changed in nova:
milestone: icehouse-2 → 2014.1
Thierry Carrez (ttx) on 2014-04-17
Changed in neutron:
milestone: icehouse-2 → 2014.1
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