Plugin Security (was: RE: Squeak viruses (was Re: [VIRUS WARNING] Re: Check this))
Andreas.Raab at disney.com
Thu Mar 2 19:28:59 UTC 2000
> > By definition, a Smalltalk system runs bytecodes and will go through
> > primitives to do any I/O like stuff.
> This is completely true, but, it's also why we need a
> different set of primitives for the Squeak plugin.
Why a different set (and what different set)?! I'd say that 90% of the
primitives are pretty secure the way they are (just because they can't even
theoretically cause you harm).
> With today's primitives, Squeak's plugin is opening a door to
> everything on your machine/network/mind?
That depends. The basic things you want to have secure are:
* File I/O,
* Socket I/O,
* External (named) primitives, and,
* Image writing.
Is there anything else you could think right of?!
> This problem has been addressed in Java, I think we should take a
> look at what they have done.
> Also, releasing this kind of programs (internet clients/internet
> client's plugins/etc) is a delicate thing to do, because
> there is a huge community of hackers/computer security related
> people looking for security problems in this kind of software.
> Security is something to have in mind (or else somebody else
> will remind you) when you release an internet client.
I certainly agree.
> > The only thing that's relatively easy to do in a Smalltalk
> > system (and a little harder in Java) is to crash the VM
> > (though this could be made harder by a VM level code validator).
> You are talking about creating an Object that points somewhere in
> memory (outside squeak's ObjectMemory),
No, actually not. What I was talking about was something like
[thisContext instVarAt: 2 "pc" put: 99999 "that'll never do"]
> lets say a ByteArray who's elements are in process Stack
> (not Squeak's VM's Virtual stack, but Squeak's VM "C" stack),
> then you can insert some (native) code into this
> stack, and change the return address of any function in the
> [let's say] VM.c file, and when that function returns,
> the microprocessor will start executing your native code.
You can't do any of this without going through primitives (at least AFAIK,
if one could that would be a *serious* security leak). But if you have to go
through a primitive you can again make sure this doesn't happen.
> We (at Core) have been thinking about this issue, and we
> think it's not easy to solve, without adding an indirection on
> the VM, or checking every access to "object's pointers" against
> a valid range of addresses.
> Am I right? what do you think?
I don't think you are right. Please try to give me an example where you
don't go through any primitive that can be trivially secured (e.g., don't
use the FFI - this one will *never* count as secure ;-) I would even argue
that you can't even create an oop from within Squeak that points somewhere
outside Squeak memory. If you can, please show us how.
More information about the Squeak-dev