[Vm-dev] I really don't understand why this doesn't crash
Mariano Martinez Peck
marianopeck at gmail.com
Wed Jun 15 08:05:12 UTC 2011
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
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.
What I wonder, and what I would really like to know is the reason why NOT to
check bounds. Is all about speed?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev