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.com
— a violation of the Java security sandbox rules.
|
|
