harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [general] compatibility packages
Date Sun, 13 Aug 2006 23:33:26 GMT
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message