openjdk team mailing list archive

[MestreLion <launchpad@xxxxxxxxxxxxxxxx>]

I thought so too Francois, but after some research it looks like
solution #1 won't solve the problem:

if a given format is registered in binfmts, and its magic or extension
matches, it *will* be considered an executable *even* if all its
detectors fail!  A +x'ed zip or docx will still fail, the error message
will be different, from "invalid file (bad magic number): Exec format
error" to "run-detectors: unable to find an interpreter for file"

So, while solution #1 is an improvement for java, for preventing it to
load 'java -jar file.docx', it would not solve this bug.

We are left with solution #2 (change binfmt from 'PK\...' magic to 'jar'
extension) and #3 (do not install a binfmt at all). #2 seems reasonable,
its only obvious (bit minor) drawback is requiring .jar files to be
actually named '*.jar'

There is also another viable approach: #3, but instead of not installing
the binfmt, install and *disable* it by default. This can be done with:

sudo --update-binfmts --disable jar

So the whole infrastructure would still be there for those who wanted it
(preferably combined with #1), and this feature could be properly
documented in java's documentation, explaining the consequences of
enabling jar, and discussing alternatives. There can even be 2 binfmts,
jar-extension and jar-magic, both disabled but easy to enable with a
single command. User can make a well informed decision and choose either
magic, extension or none.

Java fans would be 1 command away from re-enabling it, and the Ubuntu
target user would happily open zip and docx files in wine apps with no
errors or security risks.

Even with binfmt disabled, jar can still be directly executed (double-
click in Nautilus, xdg-open, etc) via desktop associations. Which works
out of the box by the way.

Win-win for me.

Do java maintainers / devs agree?

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-7 in Ubuntu.
https://bugs.launchpad.net/bugs/1172961

Title:
  update-binfmt for Jar files also impacts Office 2007 and Zip files

Status in “openjdk-6” package in Ubuntu:
  Confirmed
Status in “openjdk-7” package in Ubuntu:
  Confirmed

Bug description:
  This is the same issue already reported for the now defunct sun-java6
  package in  bug 552612 , and it also affects both OpenJDK 7 and 6. The
  description below is thus very similar:

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1172961/+subscriptions