86585 2005-03-24 14:42 0000 dev-java/sun-jdk: ebuild insecure temporary file handling 2005-03-28 09:52:59 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All All RESOLVED FIXED B3 [noglsa] jaervosz P2 minor --- 1 taviso@gentoo.org security@gentoo.org java@gentoo.org taviso@gentoo.org 2005-03-24 14:42:54 0000 the sun-jdk ebuild uses a predictable tmp filename for it's extraction log. users could abuse this by creating files at arbitrary locations via a symlink attack. example: $ ls -l /etc/nologin ls: /etc/nologin: No such file or directory $ ln -fs /etc/nologin /tmp/unpack.log # wait for root to emerge java $ ls -l /etc/nologin -rw-r--r-- 1 root root 390 Mar 24 22:36 /etc/nologin I've thought of a solution, $ cvs diff sun-jdk-1.4.2.07.ebuild Index: sun-jdk-1.4.2.07.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/dev-java/sun-jdk/sun-jdk-1.4.2.07.ebuild,v retrieving revision 1.2 diff -u -w -r1.2 sun-jdk-1.4.2.07.ebuild --- sun-jdk-1.4.2.07.ebuild 3 Feb 2005 05:43:51 -0000 1.2 +++ sun-jdk-1.4.2.07.ebuild 24 Mar 2005 22:38:56 -0000 @@ -76,6 +76,7 @@ if [ -f ${S}/lib/unpack ]; then UNPACK_CMD=${S}/lib/unpack chmod +x $UNPACK_CMD + perl -pi -e 's#/tmp/unpack.log#/dev/null\x00\x00\x00\x00\x00\x00#sg' $UNPACK_CMD for i in $PACKED_JARS; do PACK_FILE=${S}/`dirname $i`/`basename $i .jar`.pack if [ -f ${PACK_FILE} ]; then replace the hardcoded predictable name with /dev/null (note the null padding is required). luckyduck@gentoo.org 2005-03-24 16:33:05 0000 ok, patch applied koon@gentoo.org 2005-03-25 00:47:45 0000 Is this bug Gentoo-ebuild-specific ? Or does it affect every JDK installer ? In which case we should transmit to Sun. luckyduck: you should revbump so that if we issue a GLSA about this we get a "fixed" from version. taviso@gentoo.org 2005-03-25 02:28:13 0000 Koon: it's part of the installation routine from sun (ie, not gentoo's fault), so we should inform upstream? these are also affected: dev-java/sun-jre-bin dev-java/blackdown-jdk dev-java/blackdown-jre the same patch should work axxo@gentoo.org 2005-03-25 10:37:29 0000 can this be done with sed too? don't want to be DEPEND'ing on perl taviso@gentoo.org 2005-03-25 11:31:47 0000 axxo: yep, if you'ld prefer. This works fine: sed -i 's#/tmp/unpack.log#/dev/null\x00\x00\x00\x00\x00\x00#g' $UNPACK_CMD luckyduck@gentoo.org 2005-03-25 14:40:50 0000 applied to all vulnerable packages/versions. old and vulnerable revisions are removed from the tree, the new revisions which aren't vulnerable are: sun-jdk-1.4.2.07-r1 sun-jdk-1.5.0.02-r1 sun-jre-bin-1.4.2.07-r1 sun-jre-bin-1.5.0.01-r1 blackdown-jdk-1.4.2.01-r2 blackdown-jre-1.4.2.01-r1 there are versions in the tree which don't make use of $UNPACK_CMD at all. i havn't touch these version. jaervosz@gentoo.org 2005-03-25 22:12:02 0000 Arches please test and mark stable (if possible) blackdown-jdk-1.4.2.01-r2: amd64, ppc?, sparc?, x86 blackdown-jre-1.4.2.01-r1: ppc?, sparc? Jan, please check that the Sun packages have proper keywords. lu_zero@gentoo.org 2005-03-26 02:24:55 0000 ppc doesn't use blackdown. blubb@gentoo.org 2005-03-26 03:17:39 0000 blackdown-jdk-1.4.2.01-r2 stable on amd64 weeve@gentoo.org 2005-03-26 06:11:00 0000 At last check, there was no blackdown-j*-1.4.2* for SPARC. The latest we have is 1.4.1. Not sure how you want to handle that. luckyduck@gentoo.org 2005-03-26 08:11:45 0000 i think the keywords are fine now, there was no sparc and no ppc keyword in any of the vulnerable versions. version <=1.4.1 don't make use of this installing scheme and $UNPACK_CMD etc. seems that everything is fine now weeve@gentoo.org 2005-03-26 09:26:29 0000 Removing SPARC then since we aren't affected. jaervosz@gentoo.org 2005-03-27 01:23:12 0000 This one is ready for GLSA decision. koon@gentoo.org 2005-03-28 05:08:03 0000 I would vote no... My logic being that upgrading won't solve anything. People with the affected package already installed are not vulnerable to anything. Only people re-installing old versions would be. So I would remove all affected versions and close this one without GLSA. luckyduck@gentoo.org 2005-03-28 09:05:55 0000 i don't have a right to vote, but i agree. all affected versions aren't in the tree any longer. jaervosz@gentoo.org 2005-03-28 09:52:59 0000 I agree -> closing without GLSA.