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

[Robin Becker]

In article <3792835B.1A940D13@digicool.com>, Michel Pelletier
<michel@digicool.com> writes
>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.
>> 
I'm fairly sure I agree with 99% of your reply. It may be that Zope is
secure; it's certainly too large for me to verify easily. As you say the
net connection is insecure; this was almost always the case for unix
style logins. I quite like the validation approach of the monitor which
again allows direct access to everything. If as you assert the net is
insecure then I merely have to spy out a root password or two or get
admin privileges or whatever. I intended no criticism of the zope
security model other than 1) the passwords are in a meaningfully named
file, 2) the file is unencrypted and 3) there is a standard initial
manager login and password. These are not serious holes, but would get
you shown the door by the more paranoid.

OK I give up. Given the Monitor I can get at the source of any module so
I can edit/replace etc. This allows remote internals management without
breaking the Zope security policy.
>> 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 )
>
>_______________________________________________
>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 )

-- 
Robin Becker