[oss-security] [OSSA 2014-035] Nova VMware driver may connect VNC to another tenant's console (CVE-2014-8750)

Bug #1357372 reported by Marcio Roberto Starke on 2014-08-15
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
High
Gary Kotton
Icehouse
High
Jeremy Stanley
OpenStack Security Advisory
High
Jeremy Stanley

Bug Description

When spawning some instances, nova VMware driver could have a race condition in VNC port allocation. Although the get_vnc_port function has a lock it not guarantee that the whole vnc port allocation process is locked, so another instance could receive the same port if it requests the VNC port before nova has finished the vnc port allocation to another VM.

If the instances with the same VNC port are allocated in same host it could lead to a improper access to the instance console.

Reproduce the problem: Launch two or more instances at same time. In some cases one instance could execute the get_vnc_port and pick a port but before this instance has finished the _set_vnc_config another instance could execute get_vnc_port and pick the same port.

How often this occurs: unpredictable.

CVE References

summary: - Race condition in VNC port allocation when spanning a instance on VMware
+ Race condition in VNC port allocation when spawning a instance on VMware
Changed in nova:
assignee: nobody → Radoslav Gerganov (rgerganov)
importance: Undecided → High

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

Changed in nova:
assignee: Radoslav Gerganov (rgerganov) → Gary Kotton (garyk)
status: New → In Progress
Gary Kotton (garyk) on 2014-08-15
Changed in nova:
milestone: none → juno-3
tags: added: icehouse-backport-potential
Thierry Carrez (ttx) on 2014-09-04
Changed in nova:
milestone: juno-3 → juno-rc1

Marking a public security bug, given the chance you could get access to the wrong VNC console.

information type: Public → Public Security
Jeremy Stanley (fungi) wrote :

Could this behavior be controlled by a would-be attacker, or is it only up to random chance? If the former then like bug 1058077/bug 1125378 the VMT would likely deem it a security vulnerability. If the latter like bug 1255609 we would most probably not.

Changed in ossa:
status: New → Incomplete

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

commit 948ff4f3d0a159f1aed9fab65d205ede845b3eb9
Author: Gary Kotton <email address hidden>
Date: Fri Aug 15 07:15:30 2014 -0700

    VMware: prevent race condition with VNC port allocation

    When spawning some instances, nova VMware driver could have a race condition
    in VNC port allocation. This fix ensures that the lock is done on the
    actual setting in the VM configuration spec.

    Co-authored-by: Marcio Roberto Starke <email address hidden>

    Change-Id: I70fab021bbf2df418df53e5f47e19cf16dbe45ac
    Closes-bug: #1357372

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2014-10-01
Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2014-10-06
Changed in ossa:
status: Incomplete → Confirmed
importance: Undecided → Medium
Jeremy Stanley (fungi) on 2014-10-06
Changed in ossa:
assignee: nobody → Jeremy Stanley (fungi)

Since it looks like something an attacker could probably leverage repetition to eventually exploit (even if in a limited/untargeted manner), we probably need to also fix this in Icehouse and publish a security advisory for it.

Gary, would you be willing to backport your fix to the stable/icehouse branch?

Jeremy Stanley (fungi) wrote :

Marcio, is there any affiliated employer you want credited along with your name as the bug reporter in the upcoming security advisory?

Proposed impact description:

-----

Title: Nova VMware driver connects VNC to console of another tenant
Reporter: Marcio Roberto Starke
Products: Nova
Versions: up to 2014.1.3

Description:
Marcio Roberto Starke reported a vulnerability in the Nova VMware driver. A race condition in its VNC port allocation causes it to connect the wrong console, potentially even one on an instance belonging to another tenant, if these instances are created concurrently. Only Nova setups using the VMware driver and the VNC proxy service are affected.

I took a stab at resolving the merge conflicts to backport the fix for stable/icehouse (hopefully I didn't butcher it *too* badly).

Based on some early feedback in IRC from Tristan, revised impact description proposal:

-----

Title: Nova VMware driver connects VNC to console of another tenant
Reporter: Marcio Roberto Starke
Products: Nova
Versions: up to 2014.1.3

Description:
Marcio Roberto Starke reported a vulnerability in the Nova VMware driver. A race condition in its VNC port allocation causes it to connect the wrong console if instances are created concurrently. By repeatedly spawning new instances, an authenticated user may be able to gain unauthorized console access to instances belonging to other tenants. Only Nova setups using the VMware driver and the VNC proxy service are affected.

Jeremy Stanley (fungi) on 2014-10-07
Changed in ossa:
status: Confirmed → Triaged
importance: Medium → High
Thierry Carrez (ttx) wrote :

Impact desc makes it look like it will always fail to connect to the right tenant, while in most case, it does. I propose:

Title: Nova VMware driver may connect VNC to another tenant's console
"may cause" in Description

Jeremy Stanley (fungi) wrote :

Unless there are other objections, I'll request a CVE with the following impact description:

-----

Title: Nova VMware driver may connect VNC to another tenant's console
Reporter: Marcio Roberto Starke
Products: Nova
Versions: up to 2014.1.3

Description:
Marcio Roberto Starke reported a vulnerability in the Nova VMware driver. A race condition in its VNC port allocation may cause it to connect the wrong console if instances are created concurrently. By repeatedly spawning new instances, an authenticated user may be able to gain unauthorized console access to instances belonging to other tenants. Only Nova setups using the VMware driver and the VNC proxy service are affected.

Reviewed: https://review.openstack.org/126425
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ddd62ffdb136b1d75d0f47e80effe3d76cd9b4a2
Submitter: Jenkins
Branch: stable/icehouse

commit ddd62ffdb136b1d75d0f47e80effe3d76cd9b4a2
Author: Gary Kotton <email address hidden>
Date: Fri Aug 15 07:15:30 2014 -0700

    VMware: prevent race condition with VNC port allocation

    When spawning some instances, nova VMware driver could have a race condition
    in VNC port allocation. This fix ensures that the lock is done on the
    actual setting in the VM configuration spec.

    Co-authored-by: Marcio Roberto Starke <email address hidden>

    Change-Id: I70fab021bbf2df418df53e5f47e19cf16dbe45ac
    Closes-bug: #1357372
    (cherry picked from commit 948ff4f3d0a159f1aed9fab65d205ede845b3eb9)

Jeremy Stanley (fungi) on 2014-10-13
Changed in ossa:
status: Triaged → In Progress
Jeremy Stanley (fungi) on 2014-10-14
summary: Race condition in VNC port allocation when spawning a instance on VMware
+ (CVE-2014-8750)
Changed in ossa:
status: In Progress → Fix Committed
Jeremy Stanley (fungi) on 2014-10-14
summary: - Race condition in VNC port allocation when spawning a instance on VMware
- (CVE-2014-8750)
+ [oss-security] [OSSA 2014-035] Nova VMware driver may connect VNC to
+ another tenant's console (CVE-2014-8750)
Changed in ossa:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2014-10-16
Changed in nova:
milestone: juno-rc1 → 2014.2
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