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 )