[OSSA-2013-006] VNC proxy can be made to connect to wrong VM
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | OpenStack Compute (nova) |
High
|
John Herndon | ||
| | Essex |
High
|
Loganathan Parthipan | ||
| | Folsom |
High
|
John Herndon | ||
| | OpenStack Security Advisory |
Undecided
|
Russell Bryant | ||
Bug Description
Suppose a user requests a VNC token, and then deletes the VM right away, as I understand, the token is still valid not having yet exceeded the TTL. During this time if a new VM is spawned on the host and kvm reuses the port to bind the vncserver, it's possible for the user to use the old token to get access to this new VM, which could be owned by someone else.
I have seen this happening in Essex code and was wondering if this is still the case. The possible solutions are to flush the tokens on vm delete, hard reboot etc or to have a password protected VNC session.
Related branches
- Openstack Ubuntu Testers: Pending requested 2013-03-22
- Diff: 922 lines (+887/-0) 4 files modified
CVE References
| information type: | Private Security → Public |
| Changed in nova: | |
| assignee: | nobody → John Herndon (john-herndon) |
| John Herndon (john-herndon) wrote : | #1 |
Fix proposed to branch: master
Review: https:/
Step 4 of 'Steps to reproduce' should be 'nova boot server2 ..' and ideally from a different user and will still be reachable with the URL from step 2 by the first user.
| Changed in nova: | |
| importance: | Undecided → High |
| Changed in nova: | |
| milestone: | none → grizzly-3 |
Reviewed: https:/
Committed: http://
Submitter: Jenkins
Branch: master
commit 3b0f4cf6bea33e6
Author: John Herndon <email address hidden>
Date: Tue Feb 19 22:53:49 2013 +0000
Flush tokens on instance delete
Force console auth service to flush all tokens
associated with an instance when it is deleted.
This will fix bug 1125378, where the console for
the wrong instance can be connected to via the
console if the correct circumstances occur. This
change also adds a call to validate the token
when it is used. This check will ensure that all
tokens are valid for their target instances.
Tokens can become scrambled when a compute node is
restarted, because the virt driver may not
assign ports in the same way.
Change-Id: I0d83ec6c4dbfef
fixes: bug 1125378
Fix proposed to branch: milestone-proposed
Review: https:/
Reviewed: https:/
Committed: http://
Submitter: Jenkins
Branch: milestone-proposed
commit ad94a9020219333
Author: John Herndon <email address hidden>
Date: Tue Feb 19 22:53:49 2013 +0000
Flush tokens on instance delete
Force console auth service to flush all tokens
associated with an instance when it is deleted.
This will fix bug 1125378, where the console for
the wrong instance can be connected to via the
console if the correct circumstances occur. This
change also adds a call to validate the token
when it is used. This check will ensure that all
tokens are valid for their target instances.
Tokens can become scrambled when a compute node is
restarted, because the virt driver may not
assign ports in the same way.
Change-Id: I0d83ec6c4dbfef
fixes: bug 1125378
(cherry picked from commit 3b0f4cf6bea33e6
| information type: | Public → Public Security |
Fix proposed to branch: stable/folsom
Review: https:/
Fix proposed to branch: stable/essex
Review: https:/
| OpenStack Infra (hudson-openstack) wrote : | #9 |
Fix proposed to branch: stable/essex
Review: https:/
Fix proposed to branch: stable/essex
Review: https:/
Reviewed: https:/
Committed: http://
Submitter: Jenkins
Branch: stable/essex
commit e98928cf77645fd
Author: Loganathan Parthipan <email address hidden>
Date: Sat Feb 23 05:42:10 2013 +0000
Flush tokens on instance delete
Force console auth service to flush all tokens
associated with an instance when it is deleted.
This will fix bug 1125378, where the console for
the wrong instance can be connected to via the
console if the correct circumstances occur. This
change also adds a call to validate the token
when it is used. This check will ensure that all
tokens are valid for their target instances.
Tokens can become scrambled when a compute node is
restarted, because the virt driver may not
assign ports in the same way.
Change-Id: I0d83ec6c4dbfef
Fixes: bug #1125378
Reviewed: https:/
Committed: http://
Submitter: Jenkins
Branch: stable/folsom
commit 05a3374992bc8ba
Author: John Herndon <email address hidden>
Date: Fri Feb 22 20:43:58 2013 +0000
VNC Token Validation
Force console auth service to flush all tokens
associated with an instance when it is deleted.
This will fix a bug where the console for the
wrong instance can be connected to via the console
if the correct circumstances occur. This change also
makes a call to veriry vnc console tokens when a
user attempts to connect to a console. This ensures
the user is connecting to the correct console.
bug 1125378
Change-Id: I0d83ec6c4dbfef
Fix proposed to branch: stable/essex
Review: https:/
Reviewed: https:/
Committed: http://
Submitter: Jenkins
Branch: stable/essex
commit 48e81f1554ce41c
Author: Rafi Khardalian <email address hidden>
Date: Thu Mar 7 00:19:08 2013 +0000
Fixed broken vncproxy flush tokens patch
Bug 1125378 (continued)
This review (https:/
resolve a critical security issue but ended up completely breaking
the vncproxy. The wrong dict keys were being used for Essex and the
API calls were incomplete. This patch makes the proxy work again.
Change-Id: I093d522abd5be2
| Changed in nova: | |
| milestone: | grizzly-3 → 2013.1 |
| summary: |
- VNC proxy can be made to connect to wrong VM + [OSSA-2013-006] VNC proxy can be made to connect to wrong VM |
| Changed in ossa: | |
| assignee: | nobody → Russell Bryant (russellb) |
| status: | New → Fix Released |
This is easily reproducible in devstack with the latest code. I have devstack configured to use only one compute node, so the instance always lands in the same place. It appears libvirt reuses the same port, which is what causes the problem.
Steps to repro:
1) nova boot server1 --image <xxx> --flavor <yyy>...
2) nova get-vnc-console server1 novnc - keep the URL
3) nova delete server1
4) nova boot server1 --image <xxx> --flavor <yyy>...
5) Connect to the vnc console from step 2. This is the console for server2, not server1