Comments on: Java Facepalm

By: sarabjeet

sarabjeet — Wed, 10 Oct 2012 12:02:14 +0000

i really like that you are giving information on core and advance java concepts.

By: Security News #0x1D: Javageddon- the Aftermath « CyberOperations

Security News #0x1D: Javageddon- the Aftermath « CyberOperations — Mon, 03 Sep 2012 02:14:34 +0000

[...] How does last week’s Java exploit work? Thexploit points out that the problem can be exploited with simple Java code. [...]

By: ez

ez — Tue, 28 Aug 2012 19:57:26 +0000

More discussion/speculation (and backtraces) here http://www.reddit.com/r/netsec/comments/ywbhq/new_java_0day_exploited_in_the_wild/c601p5s

By: Dustin Schultz

Dustin Schultz — Tue, 28 Aug 2012 18:12:03 +0000

Post updated – indeed I had it wrong. Thanks Michael! Now just to figure out exactly why Expression (or it’s parent class Statement) is privy to execute Class.forName(“sun.awt.SunToolkit”) …

By: mihi

mihi — Tue, 28 Aug 2012 17:15:22 +0000

If you try harder, you will notice that in Java 6 you cannot call any (public) method of the SunToolkit class since untrusted code may not access the sun.* packages. And even a Class.forName() in Java 7 cannot give you a reference to SunToolkit. Therefore, having methods in SunToolkit that are disastrous to security is not the main problem (search for public classes called SecuritySupport, they have interesting methods too, or sun.misc.Unsafe as well, but they “cannot” be called since you should not get a reference to them).

The main problem (in my opinion) is that inside of the implementation of Statement the case of calling Class.forName is special cased in JDK7 – and in a way that will load even classes in restricted packages…

In other words: The change of that method to public makes it easier to exploit this issue, but even without there are enough interesting methods within sun.* that can do stuff like that. Just that you need someone trusted who is stupid enough to hand you a reference to that class as you cannot get them yourself.