Red Hat Bugzilla – Bug 1056273
CVE-2014-0023 OpenShift: install script has temporary file creation vulnerability
Last modified: 2014-11-10 04:38:23 EST
The install scripts at https://install.openshift.com/ contains a /tmp file vulnerability: : ${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="${TMPDIR}oo-install-ose-20140115-1645/vendor/bundle/ruby/${RUBYDIR}/gems/" ... RUBYLIB="${TMPDIR}oo-install-ose-20140115-1645/lib:${TMPDIR}oo-install/vendor/bundle" ... 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
Still present, we really should fix this.
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).
Statement: 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/.