Bug 1056273 (CVE-2014-0023) - CVE-2014-0023 OpenShift: install script has temporary file creation vulnerability
Summary: CVE-2014-0023 OpenShift: install script has temporary file creation vulnerabi...
Alias: CVE-2014-0023
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1056274
TreeView+ depends on / blocked
Reported: 2014-01-21 20:47 UTC by Kurt Seifried
Modified: 2021-02-17 06:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-11-06 20:29:22 UTC

Attachments (Terms of Use)

Description Kurt Seifried 2014-01-21 20:47:16 UTC
The install scripts at https://install.openshift.com/ contains a /tmp file 

: ${TMPDIR:=/tmp}
[[ $TMPDIR != */ ]] && TMPDIR="${TMPDIR}/"
cp oo-install-ose-20140115-1645.zip ${TMPDIR}/oo-install-ose-20140115-1645.zip
curl -s -o ${TMPDIR}oo-install-ose-20140115-1645.zip https://install.openshift.com/ose/oo-install-ose-20140115-1645.zip
unzip -qq -o ${TMPDIR}oo-install-ose-20140115-1645.zip -d $TMPDIR
GEM_PATH=$GEMPATH RUBYLIB=$RUBYLIB OO_INSTALL_CONTEXT=ose OO_INSTALL_VERSION='OpenShift Enterprise 2.0 - Build 20140115-1645' sh -c "${TMPDIR}oo-install-ose-20140115-1645/bin/oo-install ${cmdlnargs}"

This would result in arbitrary code execution as the user installing OpenShift,
arbitrary file overwrites and so on.

To correct this simply use bash "mktemp -d" to create a safe temporary 
directory to work within. This will of course prevent reuse of the downloaded 
content from a previous attempt however that closes a security vulnerability

Comment 2 Kurt Seifried 2014-11-04 06:25:07 UTC
Still present, we really should fix this.

Comment 3 Luke Meyer 2014-11-04 13:15:34 UTC
It seems like the way to exploit this would be:

1. As a user on a system you know will be used to run oo-install, download the installer and put it in /tmp where it would be put when the admin will try to run the install.
2. Modify so that it does whatever nefarious purpose you have in mind.
3. The admin runs oo-install, it attempts to extract itself where the malicious installer now exists, the user doesn't notice that this actually failed to overwrite what was already there and continues to run the malicious version.

Is there another way I'm not thinking of? I would expect ownership permissions would prevent anything else, unless of course the attacker owns root or the user's account, in which case protection seems out of scope.

I understand the benefits of using unpredictable temp directories, just wondering if we can still keep the downloaded assets by hardening at step 3 (make sure you successfully wrote everything you're about to run).

Comment 4 Kurt Seifried 2014-11-06 20:29:22 UTC

This issue affects the script provided on the OpenShift website. Red Hat Product Security has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

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