[Openstack-security] [Bug 1074087] Re: XenApi migration driver should not use shell=True with Popen

OpenStack Hudson 1074087 at bugs.launchpad.net
Tue Jul 9 15:20:26 UTC 2013


Reviewed:  https://review.openstack.org/34580
Committed: http://github.com/openstack/nova/commit/61ef64f48f6815e6e6bb771d2fb33ddcf2f30f40
Submitter: Jenkins
Branch:    master

commit 61ef64f48f6815e6e6bb771d2fb33ddcf2f30f40
Author: Euan Harris <euan.harris at citrix.com>
Date:   Wed Jun 26 16:57:14 2013 +0100

    xenapi: Tidy up Popen calls to avoid command injection attacks
    
     * Rewrite xenhost._run_command and xenstore._run_command to use
       utils.make_subprocess and utils.finish_process
     * Change exception raised by utils.finish_process to retain information
       needed by calls in xenhost and xenstore
    
    Change-Id: Idcdb50bededf0acde92f1774d6752043ba8f97ce
    Fixes: bug #1074087


** Changed in: nova
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1074087

Title:
  XenApi migration driver should not use shell=True with Popen

Status in OpenStack Compute (Nova):
  Fix Committed

Bug description:
  The XenApi drivers split a string to create an array for
  subprocess.Popen, rather than passing an array directly. This invites
  the potential for command injection / manipulation.

  There is no clearly valid reason to use string splitting here when
  arguments can be passed, as elsewhere, directly into Popen.

  The behavior here is present in current Trunk, Folsom, and Essex.  Per
  Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to
  perform the splitting.  In Essex, this behaviorism was present
  directly in migration/transfer_vhd.py, rather than in utils.py.
  Earlier releases have not been evaluated.

  I am not certain if this is directly exploitable. The user field is
  inserted into the generated strings used for command-line execution,
  and it does seem that Keystone allows usernames to contain arbitrary
  tokens/characters such as spaces.  It is not clear to me if the user
  field directly matches that in Keystone, if the user field is
  otherwise validated in the API, etc.  Other fields inserted into the
  command string seem to be internally generated.

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




More information about the Openstack-security mailing list