This is getting a bit off-topic, but hopefully we can finish it
quickly.
On Sun, May 18, 2003 at 09:21:04PM +0900, Tim Romero wrote:
> > The program is carefully designed so that the 'random memory
> > location', which is actually likely to be just one bit different from
> > the correct one, will probably be that of an instance of the other
> > class. I can't remember exactly how it does that. The result is that
> > the program has a reference of type A and a reference of type B to the
> > *same* block of memory. It can then set the int member through the A
> > reference and use it as an Object reference through the B reference.
>
> Well since we don't know what bit will be flip, we can't say what
> value will be changed or where it will start reading, right? But walk me
> though this. The VM now has two objects of different types referencing
> the same memory location. Now what? We are still in the sandbox in this
> case.
>
> If the flipped bit takes us out of the sandbox, which of course it could,
> we have no way of knowing what will be at that location. But at least
> now we have a reference out of the sandbox. If you know what's there,
> you have some options, but of course you have no clue where you are.
> Granted, you can write whatever crap you want into it, but I don't see
> how you can get the computer to execute anything.
I suppose you can't do that much with an Object reference. However,
what an attacker can do is look for code pointers in static data in a
VM, design a class C whose memory layout in that VM will be similar to
the structure where the code pointer is, and use a C reference rather
than an Object reference in class B. Then once the first stage of
the attack succeeds the rogue program can modify this code pointer to
point to some different code. If there is no suitable code in the
program then a similar technique could be used to write code
somewhere.
Obviously this depends on knowing a lot about the VM itself, but given
that most people will be running one of just a few VMs an attacker can
work out how to exploit just those few.
> > > It's Rube Goldberg security attack.
> > Wrong - you can embed this as a trojan horse in an apparently useful
> > applet or a servlet or something like that, which you get someone else
> > to run on their machine. They think it's restricted in a sandbox, but
> > actually it can break out. It's an attack that will work on many PCs.
>
> I just don't see how this can work in the real world. Perhaps
> you can explain. Granted, a light-bulb or a cosmic ray can screw up a
> computer's memory. It can result in a program witting to a part of
> memory that it should not be witting to. OK, that's a cool parlor trick,
> but I don't see how it is any more dangerous than just sticking a
> lightbulb over my CPU with no malicious code running.
It's *not* about writing to a random location of memory. It's about
explotiting hardware failure to break the type-checking system, and
then writing to very carefully chosen locations in memory.
--
Ben Hutchings | personal web site: http://womble.decadentplace.org.uk/
The two most common things in the universe are hydrogen and stupidity.
Received on Mon May 19 11:42:52 2003