Issues creating instance of SmallInteger
Alejandro F. Reimondo
aleReimondo at smalltalking.net
Sat May 13 13:27:10 UTC 2006
>An exploit for this would look like this:
>Object readFrom: 'SmalltalkImage current snapshot: false andQuit: true'
It is like turning off the computer...
e.g. I can do the same by hardware.
How you make the software "secure" to do not let my children
turn off my computer when I am using Squeak?
In practice, use of free scripting has bring powerfull
experiences for "power"users ussing commercial
applications in small and big products.
Smalltalk let power users talk to your system's objects,
and you can publish the hight level language you want
to be used and expose the objects they need in the
context of application.
The mechanism promoted with Parts (VS) was very interesting
and not followed by any other dialect of smalltalk (imho because
it's power requires experience in it's use to be observed).
Parts let power user's customize teh GUI of the product
following the constrains emerging from the underlying
model of the core system.
It was better than compilation because parts was loaded/saved
in binary mode and do not requires compilation (a really
----- Original Message -----
From: "Philippe Marschall" <philippe.marschall at gmail.com>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, May 13, 2006 7:20 AM
Subject: Re: Re: Issues creating instance of SmallInteger
> For the purpose of generating a SmallInteger (from XML ya know..), Object
readFrom:'42' works just fine!
Do _not_ do that. This is a _huge_ security hole. What it does it
evalutates the string. This string can be any Smalltalk code. This way
you have aribrary code execution in Smalltalk.
An exploit for this would look like this:
Object readFrom: 'SmalltalkImage current snapshot: false andQuit: true'
Number readFrom: aString
instead. This has its own problems like that
Number readFrom: 'garbage'
returns 0 but this will be fixed and at leas it's safe.
Please not that also Boolean class >> #readFrom: is borken in the same
way. This is the reason why you can execute arbitrary Smalltalk code
in every Squeak image that uses SOAP either as client or server.
Combine that with FFI and X11 root exploits and you have a nightmare.
More information about the Squeak-dev