[Seaside] Security

John McIntosh johnmci at smalltalkconsulting.com
Sun May 3 19:53:26 UTC 2009

Now be careful here the squeak VMs don't have known buffer overflow
issue, but possible buffer overflow issues could exist because many of
the primitive and standard plugins are not parnoid about the incoming
parms. The VM folks have never sat down and consider the caller of a
primitive would be unfriendly.

However this would require an attacker to execute arbitrary Smalltalk
code on your server. Of course if they can do that they own you
anyway, especially if you allow FFi or use the OSProcess plugin

On 5/3/09, Randal L. Schwartz <merlyn at stonehenge.com> wrote:
>>>>>> "Ross" == Ross Boylan <RossBoylan at stanfordalumni.org> writes:
> Ross> First, the attacker could pretend to be someone else.  I need Seaside
> to
> Ross> identify accurately who the requestor is or to reject forged requests
> Ross> before they get to my code.  Previous discussion on the list indicates
> Ross> that, with suitable precautions, an outsider can not hijack an
> existing
> Ross> session.  Can someone with a legitimate session assume another
> identity?
> Ross> Can someone without a session assume an identity?
> Seaside doesn't know "identity".  That's all in your app code.  All seaside
> is
> going to do with the incoming values is reawaken your session-saved state,
> including the state of all components.  If one of those values is your
> app-defined "identity", that's up to you to manage properly.
> Ross> Second, the request could attempt to execute some code that is outside
> Ross> the normal flow of operations.  I don't know if the latter is possible
> Ross> with Seaside; in other frameworks such as Zope it is possible (and it
> Ross> has security systems to keep this in check).  Or they could start
> Ross> traversing the object graph, even with the debugging interface off.
> Ross> Again, I'm not clear: are either of these scenarios (access to code or
> Ross> objects) possible.  Are they?
> Not possible, unless you happen to be silly enough to "eval" incoming
> arbitrary strings as Smalltalk code.
> Of course, if the Smalltalk VM has a buffer overflow problem, all bets are
> off. :) But no known bugs at this time on those.
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com

More information about the seaside mailing list