app-portage/gentoolkit / qpkg: symlink attack vulnerability hi, i have found a tmpfile / symlink attack vulnerability in qpkg (part of app-portage/gentoolkit): -- snip -- # $Header: /home/cvsroot/gentoolkit/src/qpkg/qpkg,v 1.13 2004/02/18 15:25:43 los tlogic Exp $ ID='$Id: qpkg,v 1.13 2004/02/18 15:25:43 lostlogic Exp $' VERSION=0.`echo ${ID} | cut -d\ -f3` TMP="/tmp/qpkg-${$}/" rm -rf ${TMP} mkdir -p ${TMP} PROG=`basename ${0}` # Parse args -- snip -- as you can see, qpkg creates a temporary directory in /tmp, that is highly predictable (insecure!!!), because the directoryname is derived from the pid of the qpkg process... an attacker could do a simple symlink from /etc/ to /tmp/qpk-[pidnumber] for example, and completely delete the /etc directory. the same is possible, of course, with every directory on the system (qpkg is usually invoked a root) impact: an attacker is able to delete / overwrite virtually every directory (file) on the system. solution: create a secure temporary directory (mktemp), set up a secure umask. best regards florian [rootshell]
Genone, any hint on who specifically we should call to fix that ?
After looking at this bug jstubbs noticed the same symlink problems exist for portage's handling of dispatch.conf. Jason is working on a patch for that now.
Well, personally I'd like to just drop qpkg, but I guess we can't do that :( I'll fix it in CVS but I'm not sure if I can make a release at this moment (as CVS currently has some experimental stuff, read: is broken), I have to check for that and report back later. PS: I'm on the security alias, no need to CC me (unless you want to remove me from it).
Hmm, apparently I can't access the bug when I'm not in the CC list even though I get all mails about it ...
Where are we now ? Was a patch written / put in CVS ?
added a patch for this and released pre8-r1 (arch) and pre10-r1 (~arch).
Thx Marius Time for GLSA decision. Perhaps it should be combined with bug #69147?
Yes, good idea. These are all symlink vulns in portage-related tools.
GLSA 200411-13