Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1152548 - (CVE-2014-3701) CVE-2014-3701 eDeploy: Multiple tmp file race condition flaws
CVE-2014-3701 eDeploy: Multiple tmp file race condition flaws
Status: CLOSED UPSTREAM
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Red Hat Product Security
impact=critical,public=20150317,repor...
: Security
Depends On:
Blocks: 1152549
  Show dependency treegraph
 
Reported: 2014-10-14 07:49 EDT by David Jorm
Modified: 2015-03-19 00:16 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-17 19:25:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jorm 2014-10-14 07:49:57 EDT
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 07:50:37 EDT
Acknowledgements:

This issue was discovered by Kurt Seifried of Red Hat Product Security.
Comment 3 Kurt Seifried 2015-03-17 15:45:06 EDT
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 19:25:24 EDT
This is now filed upstream https://github.com/enovance/edeploy/issues/232
Comment 5 Kurt Seifried 2015-03-19 00:16:59 EDT
Statement:

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

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