Home
  · Order
  · Contact us
  · About
Shareware
  · PMVR
  · SlideShow
Java Tools
  · JexePack
  · Jobfuscate
  · MakeInstall
Affordware
  · PhotoFinder
  · PrintEnvelope
  · WinOpen
Learning + Fun
  · NX 101
  · Pano Help
  · Bug Free C
 
DuckwareQuality by Design
 You are here: Duckware » Technology » Java security sandbox tricked   Contact us  
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.

Copyright © 2013-2014 Duckware