yahoo-eng-team team mailing list archive

Thread
Date

[Bug 1125378] Re: VNC proxy can be made to connect to wrong VM

To: yahoo-eng-team@xxxxxxxxxxxxxxxxxxx
From: OpenStack Hudson <1125378@xxxxxxxxxxxxxxxxxx>
Date: Thu, 21 Feb 2013 22:45:43 -0000
Reply-to: Bug 1125378 <1125378@xxxxxxxxxxxxxxxxxx>
Sender: bounces@xxxxxxxxxxxxx

Reviewed:  https://review.openstack.org/22616
Committed: http://github.com/openstack/nova/commit/ad94a90202193335f011888db017e557b07faf8a
Submitter: Jenkins
Branch:    milestone-proposed

commit ad94a90202193335f011888db017e557b07faf8a
Author: John Herndon <john.herndon@xxxxxx>
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: I0d83ec6c4dbfef1af912a200ee15f8052f72da96
    fixes: bug 1125378
    (cherry picked from commit 3b0f4cf6bea33e6ee1893f6e872d968b0c309f88)


** Changed in: nova
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1125378

Title:
  VNC proxy can be made to connect to wrong VM

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) essex series:
  New
Status in OpenStack Compute (nova) folsom series:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1125378/+subscriptions