XenApi migration driver should not use shell=True with Popen
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Euan Harris |
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.
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.
summary: |
- Xen migration driver should use execvp + XenApi migration driver should use execvp |
description: | updated |
Changed in nova: | |
status: | New → Triaged |
tags: | added: xenserver |
Changed in nova: | |
importance: | Undecided → Medium |
Changed in nova: | |
assignee: | nobody → Euan Harris (euanh) |
summary: |
- XenApi migration driver should use execvp + XenApi migration driver should not use shell=True with Popen |
Changed in nova: | |
status: | Triaged → In Progress |
Changed in nova: | |
milestone: | none → havana-2 |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | havana-2 → 2013.2 |
Are you still investigating this to determine if it is exploitable? The first step in handling this is to determine that. That will determine the process we use for fixing the bug (whether it needs to stay private or not).