openjdk team mailing list archive

[Rodrigo Silva <linux@xxxxxxxxxxxxxxxx>]

Package: openjdk-7-jre-headless
Version: 7u21-2.3.9-0ubuntu0.12.04.1
Severity: normal

This was filed in Ubuntu's LP, and I was oriented to file in BTS too since bugs
fixed in Debian are automatically fixed in Ubuntu after sync, so I'll paste the
description from https://bugs.launchpad.net/bugs/1172961 , and I've also added
some Debian-specif notes in the end.

The problem is that the binfmt entry for Jar files created by OpenJDK also
matches regular Zip files and Office 2007 files. This means that if you get
these files from a FAT filesystem (typically a USB stick), or an NTFS "data
partition" (common scenario when dual-booting), kernel will consider such .zip
and .docx files as executable.

This has a large impact in wine, as its shell32 ShellExecute() ends up
executing .ZIP and MS Office files (or trying to) instead of opening then in
Word, Excel, etc.

And since this is also highly exploitable, I elieve it is a security concern.

Here's how to reproduce the problem:

   $ echo foo >foo.txt
   $ zip foo.zip foo.txt
   $ chmod +x foo.zip

Now on a system without java installed if you try to run or exec that file you
would get:

   $ ./foo.zip; echo $?
   bash: ./foo.zip: cannot execute binary file
   126
   $ exec ./foo.zip
   bash: /tmp/foo.zip: cannot execute binary file
   bash: /tmp/foo.zip: Success

But on a system where sun-java6-bin has been installed you get:

   $ ./foo.zip; echo $?
   invalid file (bad magic number): Exec format error
   1
   $ exec ./foo.zip
   <xterm is gone because exec succeeded>

The reason is that Jar files look like Zip files so the content matching
pattern used by /proc/sys/fs/binfmt_misc/jar matches both. The issue is the
same with the new Office 2007 files such as docx and pptx files.

Options:
1) Make the binfmt magic distinguish between Jar files and Zip files.

    This can be done using binfmts' 'detector' option, invoking a detector
script that tests valid jar files, the same approach used by mono that
registers /usr/lib/cli/binfmt-detector-cli as its detector. This is also the
approach used by 'jarwrapper' package.

    Detector script could be as simple as:

    #!/bin/sh --
    unzip -l "$1" 'META-INF/MANIFEST.MF' 2>/dev/null | grep -q 'META-
INF/MANIFEST.MF$'

    or

    #!/bin/sh --
    jar -tf "$1" 'META-INF/MANIFEST.MF' 2>/dev/null | grep -q '^META-
INF/MANIFEST.MF$'

    (and add either unzip or fastjar package as dependency)

    Script could be discretely placed in /usr/lib/jvm/java-{6,7}-openjdk-
xxxx/jre/bin/binfmt-detector-jar , and a 'detector' line added to
[...]/jre/lib/jar.binfmt

2) Match based on the extension instead of zip's magic as documented in the
kernel example at https://www.kernel.org/doc/Documentation/java.txt

    This means only files with the .jar extension will be runnable which may be
too limiting if the goal is to make it possible to have /usr/bin binaries
actually be Java applications. However, are these really Jar files or would
they be Class files? Or would wrapping them with a Class file be ok?

    Worth mentioning that the extension approach is case-sensitive, so it would
not work with, say, *.JAR files.

    By the way... currently openjdk only register execution for jar files,
while it could also add support for compiled java classes.

3) Remove the Jar binfmt altogether.
    Do the advantages of wrapper-less execution of no-extension Jar files
justify changing the exec() behavior of zip and Office 2007 files? Are such
files actually common?

There is also an underlying philosophical question: what should a file manager
do when the user double-clicks on an executable file?
 A) fork()+exec() it and if exec() fails, then look for an association as a
fallback
 B) or look for an association first and only try fork()+exec() as a fallback
(or even have no fallback at all)

Nautilus seems to implement (B) so impact is mitigated since zip and MS Office
files are usually associated by default with File-Roller / LibreOffice. But
wine seems to implement (A), perhaps because it is bounded to mimic windows'
ShellExecute() behavior, so impact is much bigger.

Still, I think suggested option (1) fixes the problem on both sides: it keeps
Nautilus/wine happy while still allowing full "executability" of jar files,
regardless of its extension, it's an approach with very little drawbacks, if
any.

------

Debian notes: implementantion for my suggested approach depends on resolution
of BTS bug #643755 : If the detector script is installed only for current JVM,
without symlinking it to /usr/bin or using update-alternatives system (seems
overkill for a jar detector), then the binfmts entry *must* be properly removed
in postrm, otherwise a new jvm will not update binfmts and the detector will
point to an incorrect (perhaps non-existing) file. Using update-alternatives
may mitigate this, but then a more sensible should be used instead of 'binfmts-
detect-jre'



-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise-proposed'), (500, 'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-41-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openjdk-7-jre-headless depends on:
ii  ca-certificates-java  20110912ubuntu6
ii  java-common           0.43ubuntu2
ii  libc6                 2.15-0ubuntu10.4
ii  libcups2              1.5.3-0ubuntu6
ii  libfontconfig1        2.8.0-3ubuntu9.1
ii  libfreetype6          2.4.8-1ubuntu2.1
ii  libgcc1               1:4.6.3-1ubuntu5
ii  libglib2.0-0          2.32.4-0ubuntu1
ii  libjpeg8              8c-2ubuntu7
ii  liblcms2-2            2.2+git20110628-2ubuntu3
ii  libnss3-1d            3.14.3-0ubuntu0.12.04.1
ii  libpcsclite1          1.7.4-2ubuntu2
ii  libstdc++6            4.6.3-1ubuntu5
ii  multiarch-support     2.15-0ubuntu10.4
ii  openjdk-7-jre-lib     7u21-2.3.9-0ubuntu0.12.04.1
ii  tzdata-java           2012e-0ubuntu0.12.04.1
ii  zlib1g                1:1.2.3.4.dfsg-3ubuntu4

Versions of packages openjdk-7-jre-headless recommends:
ii  icedtea-7-jre-jamvm  7u21-2.3.9-0ubuntu0.12.04.1

Versions of packages openjdk-7-jre-headless suggests:
ii  fonts-ipafont-gothic  <none>
ii  fonts-ipafont-mincho  <none>
ii  libnss-mdns           0.10-3.2
ii  sun-java6-fonts       <none>
ii  ttf-bengali-fonts     <none>
ii  ttf-dejavu-extra      2.33-2ubuntu1
ii  ttf-indic-fonts-core  1:0.5.11ubuntu1
ii  ttf-kannada-fonts     <none>
ii  ttf-oriya-fonts       <none>
ii  ttf-telugu-fonts      <none>
ii  ttf-wqy-microhei      0.2.0-beta-1ubuntu1

-- no debconf information