Hello, dev-util/shtool <= 2.0.1 572 # establish a temporary file on request 573 if [ ".$gen_tmpfile" = .yes ]; then 574 if [ ".$TMPDIR" != . ]; then 575 tmpdir="$TMPDIR" 576 elif [ ".$TEMPDIR" != . ]; then 577 tmpdir="$TEMPDIR" 578 else 579 tmpdir="/tmp" 580 fi 581 tmpfile="$tmpdir/.shtool.$$" 582 rm -f $tmpfile >/dev/null 2>&1 583 touch $tmpfile 584 chmod 600 $tmpfile 585 fi 597 # cleanup procedure 598 shtool_exit () { 599 rc="$1" 600 if [ ".$gen_tmpfile" = .yes ]; then 601 rm -f $tmpfile >/dev/null 2>&1 || true 602 fi 603 exit $rc 604 } Look at line 581 and 582, symlink attack could delete arbitrary files. The gen_tmpfile is used for tarball, subst, scpp ant path actions. I think more issues could be found with this insecure temporary file creation package ocan-mysql use also shtool, maybe more others packages use also shtool. Regards.
Romang, did you try to contact upstream and negociate coordinated disclosure ?
Hello, I have send an email to upstream. I give him the link to this bug. Waiting for reply.
Hello, <rse@gnu.org>: host mx10.gnu.org[199.232.76.166] said: 550 unknown user (in reply to RCPT TO command) No more upstream avaible. Regards.
taviso/tigger will one of you take a look and confirm(/patch)? Also CC'ing maintainer.
confirmed as a abusable. suggested fix: - tmpfile="$tmpdir/.shtool.$$" - rm -f $tmpfile >/dev/null 2>&1 - touch $tmpfile - chmod 600 $tmpfile + tmpfile=`mktemp "$tmpdir/.shtool.XXXXXX"`
Aaron please provide an updated ebuild.
re-reading, don't know how you'd get a file deletion or anything scary out of this. the rm -r $tmpfile would delete the symlink, not the target of it. So, doesn't look to be abusable. Sorry for misinformation.
You were right first time, the rm then touch is a non-atomic operation, so there's a race condition. As the filename is easily predictable (pid-based), this is exploitable (in cases like this you can cause lots of system load to expand the window even more, using mktemp also contains a race condition, but to have any chance of exploiting it you must create millions of files within a very short period (microseconds?), so the attack is only theoretical, not practical).
2.0.1-r1 in CVS; x86 stable. CC'd archs please stable.
Unccing arches as they can access the bug as the alias. We should cc individual maintainers instead, until this is made public by reporter ?
Hello, Here under other non related and gentoo related packages using shtool : - SellaNMS (http://www.digitalgenesis.com/) - non gentoo related - ipcmp (http://www.digitalgenesis.com/) - non gentoo related - OOPSE ( http://oopse.org/) - non gentoo related - and others. Regards.
sparc done.
Hello, Adviso on http://www.zataz.net/adviso/shtool-05252005.txt Thxs to Gentoo Security Team ! Regards.
Advisory is public. ia64: please test and mark 2.0.1-r1 stable. Ready for GLSA vote, maybe we should wait for the other shtool-including packages to be fixed.
I would vote YES, as there is precedent for sending a glsa for this class of vulnerability (eg, 200503-14).
Also, forgot to mention, I did notify upstream via bug-shtool@gnu.org. Didn't get a return on that one, so I'm assuming it went through ok. As far as packages using shtool, grep'ing the tree only turns up net-nds/openldap and dev-libs/mm. Obviously there are more than that though. Just not sure how we'd go about finding out.
Stable on ia64.
Candidate: CAN-2005-1751 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1751 Reference: VULNWATCH:20050525 shtool insecure temporary file creation Reference: MISC:http://www.zataz.net/adviso/shtool-05252005.txt Reference: MISC:http://bugs.gentoo.org/show_bug.cgi?id=93782 Race condition in shtool 2.0.1 and earlier allows local users to create or modify arbitrary files via a symlink attack on the .shtool.$$ temporary file.
I vote YES for a grouped GLSA with bugs 94063 94057 and 93784.
I agree with Koon on an grouped GLSA.
Hmmm... Not sure the patch is sufficient. There are multiple places where $tmpfile, even created safely, is handled inappropriately : Race condition : rm -f $tmpfile >/dev/null 2>&1 touch $tmpfile Or my personal favorite : echo >$tmpfile.c "#include <assert.h>" echo >>$tmpfile.c "Syntax Error" cpp="${CC-cc} -E" (eval "$cpp $tmpfile.c >/dev/null") 2>$tmpfile.out We should definitely have a deeper look in this. And forward more complete patches upstream.
Created attachment 60117 [details, diff] shtool patch how about this, he can create whatever files he likes with .c .out or whatever then. also, mktemp is probably not portable enough for this situation.
Hello, Send the patch to upstreams. Regards.
CAN-2005-1759 for the Gentoo-discovered variants
Aaron: please bump shtool with latest taviso's patch. It should replace the original (incomplete) patch.
2.0.1-r2 in cvs. x86 stable. ia64/sparc please re-stable.
sparc stable.
Waiting on bugs 94063 94057 and 93784 for a grouped GLSA.
Hello, No answers from upstream. Regards.
php-4.3.11 includes shtool-1.6.2 (at /usr/lib/php/build/shtool) Not sure where/when/how it's used, though.
Geoff: see bug 94063 for shtool/php
GLSA 200506-08
