On Sun, Aug 13, 2006 at 06:34:47PM -0400, Geir Magnusson Jr wrote: > > > Dalibor Topic wrote: > > > First part of the problem was the JavaScript bridge, which allowed > > access to sun.* code, and the second part was sun.misc.Unsafe, which > > allows kicking the legs under the Java security mechanism in three lines > > of pure Java code, once you get access to it. > > > > The exploit only works on VMs with a sun.misc.Unsafe class, obviously. > > Microsoft's JVM is not affected. > > Are you suggesting that by the very nature of being named > 'sun.misc.Unsafe' there's a problem or might it simply be a bug in the > implementation? >
the way sun.misc.Unsafe works is that if you get access to it, you've rooted the JVM, effectively, as you can perform 'unsafe' operations on objects, basically a bit like having a good old raw C pointer to crack your way through objects in memory. It's rather trivial: Decompiled exploit code is at http://www.opensecnet.com/omfg.jad , details are at http://www.idefense.com/intelligence/vulnerabilities/display.php?id=158 and a few further sites. It's been patched by Sun a while ago, too, fortunately, but no details on the fix are available. ;) > If we took the j.u.c code and renamed the package, we'd be ok? We'd not share an actively used vulnerability vector with Sun's VM, at least. There was a CERT warning about the bug being exploited in the wild just a few months ago, which makes me uncomfortable having the class around in our VMs. Sun's design in this case appears to be sub-optimal, as by having a public class that is accessible accross packages and can be used to perform unsafe operations, they are adding another line of defense, which must not fail, in order for the JVM to remain uncompromised. A better design for such unsafe operations seems to be to put them in package-private classes and to not expose them to arbitrary code in other packages. That's essentially what I suggested a few mails ago regarding j.u.c. code: factoring the VM-specific, unsafe operating into their own package-private classes, hopefully with APIs that make sense to us, and using that instead of emulating the interna of Sun's VM. cheers, dalibor topic > geir > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
