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).
ok, patch applied
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.
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
can this be done with sed too? don't want to be DEPEND'ing on perl
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
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.
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.
ppc doesn't use blackdown.
blackdown-jdk-1.4.2.01-r2 stable on amd64
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.
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
Removing SPARC then since we aren't affected.
This one is ready for GLSA decision.
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.
i don't have a right to vote, but i agree. all affected versions aren't in the tree any longer.
I agree -> closing without GLSA.
