Plugin Security (Was Re: How do I create a SqueakPlugin.image from a 2.9a ?)

Bert Freudenberg bert at isg.cs.uni-magdeburg.de
Tue Jan 23 08:20:57 UTC 2001


On Mon, 22 Jan 2001, Luciano Notarfrancesco wrote:

> Removing write access to files is not enough. I think
> I can manage to write to an arbitrary place of the
> memory (and thus execute arbitrary code) using
> #become:. And there might be other ways to do this
> too... like replacing a CompiledMethod by a primitive
> method with primitive 117 (externalCall) and put in
> the first literal an array like described in
> Interpreter|primitiveExternalCall but with the
> appropiate address in the last position. I'm not sure
> this will work... I never tryed it.

At least jumping to an arbitrary address using that mechanism works:

	"Exploit some prim 117 - FloatArray>>#at: does nicely"
	(FloatArray new: 1) at: 1. "make sure function is loaded"
	(FloatArray compiledMethodAt: #at:)
		literals first at: 4 put: 42. "Manipulate address"
	(FloatArray new: 1) at: 1. "Call it - BOOM!"

Oh my ...! I thought the actual function address was stored in
the VM primitive table, and the CM literal was only a handle to that
structure. What performance hit would that additional redirection be? I
guess only a minor one?

To exploit this for something else than crashing the image one would need
to get at the actual memory address of an object from within Squeak. I
guess that's not impossible?

-- Bert





More information about the Squeak-dev mailing list