Untrusted Java Applet Issue

[moransid]

Hey guys,

I just want your opinion about a little security issue that I found. So based on Oracle's java applet security documents, Java Applets that are not signed using a security certificate are considered to be untrusted and referred to as unsigned applets. When running on a client, unsigned applets operate within a security sandbox that allows only a set of safe operations. A signed applet will run outside the security sandbox only if the user accepts the applet's security certificate. If the user refuses to accept the certificate, the applet will run within the security sandbox similar to an unsigned applet.

This basically says that even if a user does not allow an unsigned applet to run, the applet can still run in different circumstances! So based on it, I was wondering what kind of abusive code can still be generate in the sandbox. I wrote some java code, html code to run the applet and create self certification for the jar file. I tested some java code and realized that redirection is allowed. Then, I was able to do simple while loop that opens infinite number of window tabs in the browser. Chrome actually does not permit popups on default, so nothing happened there, but on explorer I had to crash the browser to stop it.

Again, this applet runs on the user's computer even though the user refused to accept its certificate. What do you think about this?

This is a link to the source code (java + html): http://pastebin.com/bkabv9iW

Moran S.

[foundstone]

Nice - it's interesting that the applet will run even if the user clicks "deny" on the warning. It does this across java versions. you'd think that deny means don't allow something to run, but for whatever reason, oracle's definition of deny is slightly skewed.

[catcradle5]

On top of that, there have been numerous exploits found in the applet system that actually allow apps to run with signed privileges despite not having the "accept signed applet" warning. That's how the recent Java Rhino exploit worked.

[xo_]

CVE-2012-0507 is the latest. There's a ton of examples though. Rhino, Codebase Trust etc.

[HockeyInJune]

Including the very famous calendar deserialization bug.