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

[Mariano Martinez Peck]

On Wed, May 18, 2011 at 2:12 PM, Gerardo Richarte <gera at corest.com> wrote:

>
> 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 :)
>

That's exactly what I think it is happening. I am just accessing slot of
other object. Likely I am still inside the ObjectMemory of the VM.
Maybe if this happens to the last object I could go outside and crash.


> 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.
>

Yes, but this is already possible with some other primitives ;)


>
> 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.
>


yes.
What I wonder, and what I would really like to know is the reason why NOT to
check bounds. Is all about speed?

Thanks


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110615/2686ec8e/attachment.htm