[OSSA-2013-006] VNC proxy can be made to connect to wrong VM
Bug #1125378 reported by
Loganathan Parthipan
This bug affects 6 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
John Herndon | ||
Folsom |
Fix Released
|
High
|
John Herndon | ||
OpenStack Security Advisory |
Fix Released
|
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
lp://staging/~james-page/nova/folsom-resync
- Openstack Ubuntu Testers: Pending requested
-
Diff: 922 lines (+887/-0)4 files modifieddebian/changelog (+31/-0)
debian/patches/CVE-2013-0335.patch (+378/-0)
debian/patches/CVE-2013-1838.patch (+476/-0)
debian/patches/series (+2/-0)
CVE References
information type: | Private Security → Public |
Changed in nova: | |
assignee: | nobody → John Herndon (john-herndon) |
Changed in nova: | |
importance: | Undecided → High |
Changed in nova: | |
milestone: | none → grizzly-3 |
information type: | Public → Public Security |
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 |
no longer affects: | nova/essex |
To post a comment you must log in.
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