Bug 1152548 (CVE-2014-3701)

Summary: CVE-2014-3701 eDeploy: Multiple tmp file race condition flaws
Product: [Other] Security Response Reporter: David Jorm <djorm>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED UPSTREAM QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: grocha, jrusnack, mjc, security-response-team, tdecacqu, weli
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-17 23:25:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1152549    

Description David Jorm 2014-10-14 11:49:57 UTC
Multiple tmp file race condition flaws were found in eDeploy. One of these flaws allowed a local attacker to overwrite a kernel image that would be used on nodes provisioned by eDeploy. In combination with an unauthenticated remote code execution exploit, a remote attacker could use this flaw to compromise the kernel image provisioned by eDeploy.

Comment 1 David Jorm 2014-10-14 11:50:37 UTC
Acknowledgements:

This issue was discovered by Kurt Seifried of Red Hat Product Security.

Comment 3 Kurt Seifried 2015-03-17 19:45:06 UTC
Multiple tmp vulns, some leading to things like kernel modification, packages 
being installed as root, etc. This means any local access == root access 
trivially.

./server/upload-health.py:$ curl -i -F name=test -F file=@/tmp/hw.lst http://localhost/cgi-bin/upload.py
./server/edeploy.conf:LOCKFILE=/tmp/edeploy.lock
./server/upload.py:$ curl -i -F name=test -F file=@/tmp/hw.lst http://localhost/cgi-bin/upload.py
./server/upload.py:    lock_filename = config_get('SERVER', 'LOCKFILE', '/tmp/edeploy.lock')
./tests/run_kvm.sh:LOCKFILE=/tmp/edeploy.lock
./docs/eDeployUserGuide.rst:   LOCKFILE = /tmp/edeploy.lock
./build/init.common:    [ -d /tmp ] || mkdir /tmp
./build/init:                        cp $d/boot/vmlinuz*$KVER* /tmp/vmlinuz || give_up "Kexec: Unable to copy kernel"
./build/init:                            cp $d/boot/initrd*$KVER* /tmp/initrd.img || give_up "Kexec: Unable to copy initrd"
./build/init:                            cp $d/boot/initramfs*$KVER* /tmp/initrd.img || give_up "Kexec: Unable to copy initrd"
./build/init:                            kexec -l /tmp/vmlinuz --initrd=/tmp/initrd.img --append="root=${root}${BOOT_ARG}"
./build/base.install:                chroot $target rpm -ivh "/tmp/${MEGACLIVER}_MegaCLI_Linux/Linux MegaCLI ${MEGACLIVER}/MegaCli-${MEGACLIVER}-1.noarch.rpm"
./build/base.install:        do_chroot $target dpkg -i /tmp/$package_name
./build/img.embedded:LOCKFILE=/tmp/edeploy.lock
./build/infiniband:    wget --no-verbose 'http://cs.stanford.edu/pub/mirrors/ubuntu/ubuntu/pool/universe/s/sdpnetstat/sdpnetstat_1.60-1ubuntu2_amd64.deb' -O ${dir}/tmp/sdpnetstat_1.60-1ubuntu2_amd64.deb
./build/infiniband:    do_chroot $dir dpkg -i /tmp/sdpnetstat_1.60-1ubuntu2_amd64.deb
./build/infiniband:    do_chroot $dir rm /tmp/sdpnetstat_1.60-1ubuntu2_amd64.deb
./build/remote-install.sh:scp "$SCR" "$DST":/tmp/
./build/remote-install.sh:ssh "$DST" bash /tmp/$(basename $SCR)
./build/img.install:BOOT_MOUNT_POINT=/tmp/$2-$3.tmp
./build/upgrade-from:/tmp/
./src/health-client.py:    HP.start_log('/var/tmp/health-client.log', logging.DEBUG)
./src/health-server.py:    HP.start_log('/var/tmp/health-server.log', logging.DEBUG)
./tools/jenkins-build.sh:if [ -f /var/tmp/froze-builds ]; then
./tools/grapher/grapher:            epilog="Example: \ngrapher -g histogram -k cpu,logical,bandwidth_1G '/tmp/*.hw'")

Comment 4 Kurt Seifried 2015-03-17 23:25:24 UTC
This is now filed upstream https://github.com/enovance/edeploy/issues/232

Comment 5 Kurt Seifried 2015-03-19 04:16:59 UTC
Statement:

Red Hat does not currently ship eNovance edeploy in a product form and as such this issue has been filed upstream.