Bug 790730 - (CVE-2012-0860) CVE-2012-0860 rhev: vds_installer insecure /tmp use
CVE-2012-0860 rhev: vds_installer insecure /tmp use
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 790736 790742 790747 850708
Blocks: 772458 850878
  Show dependency treegraph
Reported: 2012-02-15 04:40 EST by Petr Matousek
Modified: 2014-09-08 02:58 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-17 02:08:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Petr Matousek 2012-02-15 04:40:45 EST
When installing new host, RHEV-M connects to the host via ssh as root and copies vds_installer.py script into /tmp. vds_installer downloads deployUtil.py and vds_bootstrap.py via curl.

If we look into python docs [1], it clearly outlines the module search path. The first bullet says that:

"the directory containing the input script (or the current directory)."

is searched when the module to be imported is not built-in. In our case both the directory containing the input script and current directory is /tmp.

  [1] http://docs.python.org/tutorial/modules.html#the-module-search-path

To exploit the flaw you just need to create any of the imported modules in /tmp and it gets run as root upon host installation.

Other exploit might be to pre-create /tmp/deployUtil.py, wait for vor vds_installer to download it from RHEV-M and then change the content before it's imported/executed.

Either way, copying and running python scripts from /tmp is really bad idea. Use private directory in /tmp for scripts and logs.

vds_installer also creates log files with semi-random names which are prone to symlink attacks.

A local, unprivileged user on the host to be installed/addedd to RHEV-M could use this flaw to escalate their privileges.
Comment 4 Petr Matousek 2012-12-04 03:26:56 EST

This issue does affect Red Hat Enterprise Virtualization 2 and 3.

Red Hat Enterprise Virtualization 2 is now in Production 2 phase of the support and maintenance life cycle. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Virtualization Life Cycle: https://access.redhat.com/support/policy/updates/rhev/.
Comment 5 errata-xmlrpc 2012-12-04 13:53:41 EST
This issue has been addressed in following products:

  RHEV-H and Agents for RHEL-6

Via RHSA-2012:1508 https://rhn.redhat.com/errata/RHSA-2012-1508.html
Comment 6 errata-xmlrpc 2012-12-04 14:21:42 EST
This issue has been addressed in following products:

  RHEV Manager version 3.x

Via RHSA-2012:1506 https://rhn.redhat.com/errata/RHSA-2012-1506.html
Comment 7 Alon Bar-Lev 2014-03-16 16:42:56 EDT

Any reason this bug is still opened?

Comment 8 Petr Matousek 2014-03-17 02:08:34 EDT
Hello, Alon.

(In reply to Alon Bar-Lev from comment #7)
> Any reason this bug is still opened?

No reason. Closing.


Note You need to log in before you can comment on or make changes to this bug.