| 2013-04-25 23:22:07 |
MestreLion |
bug |
|
|
added bug |
| 2013-04-25 23:22:39 |
MestreLion |
information type |
Private Security |
Public |
|
| 2013-04-25 23:29:07 |
MestreLion |
bug task added |
|
openjdk-6 (Ubuntu) |
|
| 2013-04-25 23:45:27 |
MestreLion |
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) then they become 'almost' executable. 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 may not be possible.
2) Match based on the extension instead as documented in the kernel Documentation/java.txt file.
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?
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?
1) fork()+exec() it and if exec() fails, then look for an association as a fallback
2) 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 option 2 so it's not impacted by this issue. |
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 may not be possible.
2) Match based on the extension instead as documented in the kernel Documentation/java.txt file.
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?
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?
1) fork()+exec() it and if exec() fails, then look for an association as a fallback
2) 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 option 2 so it's not impacted by this issue. |
|
| 2013-04-26 08:13:16 |
MestreLion |
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 may not be possible.
2) Match based on the extension instead as documented in the kernel Documentation/java.txt file.
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?
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?
1) fork()+exec() it and if exec() fails, then look for an association as a fallback
2) 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 option 2 so it's not impacted by this issue. |
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. |
|
| 2013-04-26 08:21:18 |
Launchpad Janitor |
openjdk-6 (Ubuntu): status |
New |
Confirmed |
|
| 2013-04-26 08:21:18 |
Launchpad Janitor |
openjdk-7 (Ubuntu): status |
New |
Confirmed |
|
| 2013-04-26 09:32:52 |
MestreLion |
bug |
|
|
added subscriber jack phinney |
| 2013-05-03 00:09:46 |
MestreLion |
attachment added |
|
Add more icon sizes for manager launcher https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1172961/+attachment/3663105/+files/0001-Added-more-icon-sizes-for-manager-launcher-LP-117362.patch |
|
| 2013-05-03 00:10:39 |
MestreLion |
attachment added |
|
Improved manager launcher https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1172961/+attachment/3663106/+files/0002-Improved-manager-launcher.patch |
|
| 2013-05-03 00:17:30 |
MestreLion |
attachment removed |
Add more icon sizes for manager launcher https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1172961/+attachment/3663105/+files/0001-Added-more-icon-sizes-for-manager-launcher-LP-117362.patch |
|
|
| 2013-05-03 00:17:43 |
MestreLion |
attachment removed |
Improved manager launcher https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1172961/+attachment/3663106/+files/0002-Improved-manager-launcher.patch |
|
|
