Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.