[Vm-dev] I really don't understand why this doesn't crash

Gerardo Richarte gera at corest.com
Wed May 18 12:12:52 UTC 2011


On 05/18/2011 05:40 AM, Mariano Martinez Peck wrote:
> Now, I run this test:
>
>     | inst |
>     inst := AnotherClass new.
>     inst age: 42.
>     (FooClass >> #foo) valueWithReceiver: inst arguments: #()
>    
>
> So...I am evaluating the CompiledMethod installed on #foo on "inst".
> The compiledMethod has a bytecode (04) for accessing the var5. But
> "inst" only have one instVar.
may be it IS accessing outside the bounds of the object, but "luckily"
peeking at another object, where there is a 1. var5 is the 5th slot, and
that'll probably be in the middle of the next object. Try other's, for
example, var2, which would be the bytes just after the object, and quite
likely the pre-header of the next object, which, may or may not be a
valid oop... what's in the first word of Squeak objects? does it look
like a tagged object (integer)? I know there are different formats of
objects, and I don't really need an answer, but that's the question you
should be answering :)

of course another option is if fetchPointer:ofObject: does any bounds
checking, in which case I don't understand what the 1 means.

and lastly but not less, you have found 2 security problems in the VM
(may be just one, ok).

The first one is at a language level, where you can break the
encapsulation of objects by executing an arbitrary CompiledMethod in any
object.

The second is more severe in my opinion, and it's that you can access
(read and also write) arbitrary memory addresses in the VM process, and
that normally means arbitrary native code execution. This bug is not due
to valueWithReceiver: but rather because fetchPointer:ofObject: and the
writing counterpart, don't check bounds.

    gera

    gera


More information about the Vm-dev mailing list