[Seaside] Re: Buffer Overflow

[nicolas cellier]

Lukas Renggli a écrit :
>> Is there any need to worry about  buffer overflow security holes in Seaside?
> 
> The short answer is "no". The worst thing that could possibly happen
> is that an exception is throw.
> 
> The long answer is "very unlikely". I have seen situations where
> objects could access state outside their actual object boundaries,
> e.g. if you have a corrupted class hierarchy. If you don't let users
> evaluate Smalltalk code coming from the web this should be no problem.
> 
>> I ask only because #textAreaInput has no way to constrain the ³size² of the
>> data (whereas #textInput has #maxLength:).
> 
> That provides no security at all. Web browser are free to ignore these
> attributes.
> 
> Lukas
> 

Yes, with full access to Smalltalk language, you can manipulate 
bytecodes and generate some overflow... But then, why to use bypath and 
crooked ways when you can modify the program simply with source code!

Moreover, due to the dynamic nature of objects, and memory relocation, 
exploiting overflows would be a sport harder to play than with static 
languages i guess.

Still, you might want to allow limited use of Smalltalk syntax.
For example, you want to allow your users to feed a web form with 
interpreted expressions like [2/3], [3+4] or [Time now + 1 hour]...

It is not that difficult to create a Smalltalk compiler restricted to 
evaluating doIt, and restricted to a subset of "safe" classes and "safe" 
methods.
What is difficult is to define a consistent set of such classes and 
methods, whithout security holes.

You have to remove as much reflexivity as you can.
To name few:
- The pool of global variables must not refer to itself
- Very generic message like #basicAt:put: or the power of #become: or 
the one that enable class creation or changing methodDictionary are not 
the safe kind.
- And thisContext special variable should obviously be disabled.

Nicolas