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 Tricked by HTTP Redirect   Contact us  
Java Security Sandbox tricked
by a simple HTTP Redirect

(September 1, 2013; VU#820510; S0391632; other vulnerabilities)

UPDATE: It appears that Java 7 update 51 fixes this security hole.

Background: It is well known and understood that the Java security sandbox will only allow an applet to communicate back with the host/computer that the applet came from (there are ways for other hosts to grant permission, but that is not at issue here).

The security flaw: When the JAR file pointed to in an <applet> tag redirects to another server, java security is tricked by the Java caching mechanism. When the applet is run for the first time, Java security properly thinks that the JAR file came from the final redirected location. However, when the applet is run a second time, Java security thinks that the JAR came from the original (pre-redirected) location. And in both cases, Applet.getCodeBase() returns incorrect information.

The security risk: Extremely low in the demonstrated case. At issue is the technical expertise of the Oracle Java security team, because the 'Location' displayed in security dialogs is completely wrong (not even the correct server).

Live Demonstration: Run the live javatest-coderedirect.html web page in Java 7 update 25 (1.7.0_25). This applet on this web page looks like this:
<applet codebase="http://www.panohelp.com/" archive="test.jar" ...>
<param name="img" value="http://www.panohelp.com/.../thinproof.jpg">
</applet>
Then, on www.panohelp.com, the JAR does NOT exist. Instead, there is this HTTP redirect:
Redirect /test.jar http://www.maebilt.com/xxx.jar
Then, on www.maebilt.com, the JAR is actually found:
08/31/2013 09:45 AM 8,443 xxx.jar
First time run: The first time the live test is accessed (or, when the java web browser and the Java cache are cleared), the end-result is that java security correctly figures out where the JAR came from:
security: Grant socket perm for http://www.maebilt.com/xxx.jar : java.security.Permissions@7970f9 ( ("java.net.SocketPermission" "www.maebilt.com" "connect,accept,resolve") )
But note that the 'Location' in the security popup (seen right) is wrong/tricked, and the Java applet, when run also gets the wrong codebase:


Second time run: The second time the live test is accessed, the results are that Java is tricked by the Java cache (reports that it finds the JAR at a non-existent location and non-existent name):
CacheEntry[http://www.panohelp.com/test.jar]: ...,length=8443
Resulting in an applet from maebilt.com being granted full access to panohelp.com
security: Grant socket perm for http://www.maebilt.com/xxx.jar : java.security.Permissions@1816088 ( ("java.net.SocketPermission" "www.panohelp.com" "connect,accept,resolve") )
The 'Location' in the security popup is still the same as before (seen upper right), and wrong, but this time, the applet can access the thinproof.jpg image from www.panohelp.com (as seen in the screen snapshot below) — even though the applet JAR code originates from www.maebilt.coma violation of the Java security sandbox rules.



Copyright © 2013-2014 Duckware