[Zope] Re: [Zope-dev] Introspection, managing External Methods?

[Michel Pelletier]

Robin Becker wrote:
> 
> In article <lswvvxkauu.fsf@aldous.digicool.com>, michel@digicool.com
> writes
> >Robin Becker <robin@jessikat.demon.co.uk> writes:
> >
> ...
> >XML-RPC worms (now THAT would be cool!).  The last thing we want to
> >see is a back orifice for Zope, which is exactly what I think could be
> >developed if we ever provided a hole through Zope's security machinery.
> >
> >-Michel
> in which case why allow any external methods since these allow exactly
> the things you wish to forbid.

Because you need access to the filesystem and write permission to the
Extensions directory to edit external methods.
> 
> Sitting at a terminal I can create a hole this hole which is propagated
> via Zope. What is the difference if the hole is programmed via Zope.
> 
> Should I have less faith in the passwd system than I do in the security
> features of Zope?

This thread could probably use some jargon control.  Zope's security
model and features are secure.  If you are one user, and you do not have
permission to do something or edit something, then you will not be
allowed to do it.  This is not to say that there might not be holes, but
there are holes everywhere in software, and the open source nature of
Zope means this holes can be quickly fixed.

The insecure part in the chain has nothing to do with Zope's security
model.  The problem is how Zope *authenticates* you to find out who you
are.  Currently Zope uses HTTP Basic authentication because that is the
only method that browsers support (it is, of course, possible to write a
browser that supports a much more secure form of authentication, but
none support any standard).  The problem with HTTP Basic is that your
password is sent, on the network between you and Zope, in the clear
(meaning it is not encrypted).  There are any number of tools a Bad Guy
can use between you and your server to sniff out this password.  Note
that this is NOT a limitation in Zope.  If HTTP had a more secure
authentication mechanism, we'd use it.  Also not that there are lots of
ways of nailing this down, for example not allowing /manage URLs from
anywhere but inside your network (which everyone *should* be doing), or
over an SSL connection.

So, if you do not take any other security precautions (SSL, URL
detection) Zope in it's stock configuration is suceptable to a
man-in-the-middle attack.  Since Zope doesn't allow you to edit things
directly on the filesystem, or execute arbitrary Python code, the worst
someone could do is delete your whole site and then pack it (but then
you would still be able to restore it from the Data.fs.old file) thus
giving you a little bit of downtime.  If Zope let you edit external
methods (thus being able to execute arbitrary Python code) then this Bad
Guy could do anything on your computer that the Zope processes owner can
do.  One sick little possibility is replacing your z2.py script with a
trojan horse with the hope that you will run z2.py as the root user. 
z2.py takes the precaution of changing itself to the user 'nobody' if
it's run as root, but an amateur Python programmer could quicky change
this to add a new user with root level permissions to your computer
before z2.py changed itself to nobody.  Voila, someone else owns your
computer.

-Michel


> --
> Robin Becker
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (For developer-specific issues, use the companion list,
> zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )