Java security sandbox tricked into
granting full computer access to Applet
(September 4, 2013; VU#810566; S0391991; other vulnerabilities)
New JAR file attributes: The
release notes
for Java 7 update 25 talk about new
permissions and codebase attributes in the MANIFEST.MF JAR file.
According to Oracle,
"These attributes are used to verify that the application is requesting
the correct permissions level and is accessed from the correct location."
The security problem: Java 7 update 25 (1.7.0_25) will enforce
permissions and codebase
MANIFEST.MF attributes only when an Applet is run from a web server, but
Java will ignore permissions
and codebase MANIFEST.MF attributes when the applet is run locally
from any local file system.
The implications: A Java applet, code-signed to only run in the Java security sandbox, and
run on one very particular web site -- can be repurposed and run with
all-permissions from the local file system.
The security risk: Unknown. It all depends upon the repurposed Java applet.
Example ONE: Running an all-permissions applet in a sandbox:
Take Oracle's JavaDetection.jar applet
(run from java.com)
that is code-signed by Oracle with:
Codebase: www.java.com java.com
Permissions: all-permissions
So, signed for full access to the computer, and may only be run on java.com.
And sure enough, when run from a web server, the security popup (immediately right)
clearly shows that the applet wants all-permissions to run.
However, create a folder on your local computer, for example
c:\javatest\, and place Oracle's http://www.java.com/applet/JavaDetection.jar
Applet inside the folder, and this index.html:
<html><body>
<applet archive=JavaDetection.jar code=JavaDetection.class width=1 height=1>
<param name="permissions" value="sandbox">
</applet>
</body></html>
Now open up the index.html, and notice that the security popup is now
running the applet inside a sandbox (see popup above right).
Example TWO: Running a sandboxed applet with all-permissions:
Take Duckware's javahelp.jar
(view web page).
It is code-signed to only run inside the security sandbox
Permissions: sandbox
And sure enough, when run from a web server, the applet says that it will
be run in the security sandbox (see security popup right).
However, place the following index.html and
http://www.duckware.com/support/javahelp.jar
into c:\javatest\:
<html><body>
<applet archive=javahelp.jar code=javahelp.class width=800 height=600>
</applet>
</body></html>
Notice that there is no permissions param in the applet tag.
The result is that Java will gladly attempt to run the applet
with all-permissions, totally ignoring the Permissions: sandbox
that is inside the code-signed JAR (see security popup right).
SOLUTION: When there is a Permissions tag in a code-signed MANIFEST.MF
file that MUST be used (and can not be changed by an applet param). Oracle needs
to get serious about Java security. Since a MANIFEST.MF should contains
a permissions setting, the permissions applet param MUST be deprecated (because it
is not code-signed).
Oracle REALLY needs to get serious about code signing JAR files. The code signing
process MUST PRODUCE AN ERROR message if Permissions, Codebase, or
Application-Name are missing from the MANIFEST.MF file.
The intent of the publisher must be clear, unambiguous, and code-signed.
And of course, Oracle can enforce this at run-time because signed JAR's should
(must!) also have a timestamp. So, any JAR produced after a time deadline that
Oracle sets, must have those MANIFEST.MF settings. Otherwise the Java VM should
refuse the run the JAR, because Publisher intent is ambiguous.
|
|
