Re: [Zope] Re: [Zope-dev] Introspection, managing External Methods?
Robin Becker <robin@jessikat.demon.co.uk> writes:
In article <199907181357.XAA01659@mbuna.arbhome.com.au>, Anthony Baxter <anthony@interlink.com.au> writes
This has come up on a number of occasions - the problem is that an external method can subvert all the protections and access control that Zope provides.
Having said that, there's nothing stopping you (or someone else) writing an external method that allows you to edit external methods. :)
Anthony
Yes I know that external methods can do anything. But since the manager can destroy the site what's wrong with allowing editing only for the manager. I realise that malicious managers could wipe the hard disk if the manager user could, but then so can the manager sitting at the console.
The problem here is that Zope can have many concepts of a 'manager'. Someone you trust with managerial rights in /some/backwater/zope/folder is as much a 'manager' as a top level manager, only restricted in place, not permission. If you give a user the 'Manager' role, they will have the permission to 'Edit External Methods' unless you explicitly turn it off. Another reason is that HTTP is not the World's Most Secure Protocol. In fact, HTTP Basic authentication is downright scary. Remember, external methods can do more than just whack your site, they can do anything to the filesystem the Zope process owner can do. Including something more sinister than just mere deletion (which any sys admin worth her salt should be able to restore in minutes) such as password sniffing trojan horses and possibly even something kinda wild like 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 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.
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? -- Robin Becker
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 )
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
On Mon, 19 Jul 1999, Robin Becker wrote:
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 That depends upon your security policy. Just remove telnetd from inetd.conf, forbid nonanonymous ftp logins, and don't use POP3 with login accounts. Actually, in our case, with the exception of the root account (and the nonroot account of the root), no login accounts carry any passwords. Only way to access the box for priviledged users (meaning they DO have login access) is by providing the correct private ssh key. 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 But you don't spy out root passwords nowadays. And if you do, the admin in question deserves all the bullshit that will come his way :)
There are at least the following ``free'' ways to protect against Internet sniffers: -) ssh1. -) telnet-ssl. -) vpnd.
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. ad 3) Ok, changing the standard superuser password is natural. Perhaps it should be random generated. ad 2) Well Zope security works on a different level. Having access to the files constituting the Zope installation is equivalent to being the super user of this installation. Differently put, Zope users are ``subusers'' of the Unix Zope super user (the uid used to run Zope). ad 1) see 2.
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. Again, Monitor access is equivalent with Unix login level access. The shell just happens to be called python, not /bin/sh ;)
Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
On Sun, 18 Jul 1999, 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. Well, that's why they have to be installed in the filesystem. A mere Zope site manager password is not enough for this :)
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. The difference is authentication. I might allow some dummies management access to Zope. Allowing the user to add his own external methods without administration intervention is like allowing the user to install his own CGI scripts. This can go wrong very fast.
Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
participants (4)
-
Andreas Kostyrka -
Michel Pelletier -
michel＠digicool.com
-
Robin Becker