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

[Marcio Roberto Starke]

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.

[OpenStack Infra (hudson-openstack)]

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

[John Garbutt (johngarbutt)]

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

[Jeremy Stanley (fungi)]

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.

[OpenStack Infra (hudson-openstack)]

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

[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)]

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.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/126425

[Jeremy Stanley (fungi)]

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.

[Thierry Carrez (ttx)]

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)]

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.

[OpenStack Infra (hudson-openstack)]

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)