How (in)secure is Zope?
Dear Zope community, please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know. There are people claiming that Zope opens a system to quite some level, others claim the opposite. Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"? And, pondering more on security, are these issues, if they exist, bounded to Zope itself, or becomes a system generally more "open" to attacks, after Zope was installed? I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone. thanks so much in advance -- chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
On March 13, Christian Tismer wrote:
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
How secure is your wallet? You will never answer this until you define what you mean by "security", and what you are securing *against*. Zope is perfectly secure or some uses, and perfectly insecure for others. For example, for safe delegation of responsibility within a web application, in a trusted environment, Zope is "secure". However, as a mission-critical service exposed to the internet, it is wide-open. a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
Adrian van den Dries wrote:
On March 13, Christian Tismer wrote:
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
How secure is your wallet?
I won't tell you (since this is insecure:).
You will never answer this until you define what you mean by "security", and what you are securing *against*.
This is quite a silly argument, IMHO. My simple question was alike "what kind of insecurity do I buy when I install Zope on my server". This question is asked from the POV of a system administrator. It is simple: Do I increase the possibility of somebody to obtain root rights, or do I not?
Zope is perfectly secure or some uses, and perfectly insecure for others.
Either it is secure for my server, in the sense I depicted above, or it is not. I don't see any relevance to any use, if I am using it on an exposed server in the internet. I think there should be one single answer, nothing else is relevant. ?
For example, for safe delegation of responsibility within a web application, in a trusted environment, Zope is "secure".
Run in an intranet service? Run on the same machine? What is your definition of "secure", if there is any?
However, as a mission-critical service exposed to the internet, it is wide-open.
Why is it wide open, and when is it wide open? Thanks a lot, but this doesn't help me at all. sorry - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
This is quite a silly argument, IMHO.
No its not, you can't give exact answers to inexact questions with no prior understanding of how much foreknowledge the audience has. Especially when you're talking about security.
It is simple: Do I increase the possibility of somebody to obtain root rights, or do I not?
Given that there is no good reason to run Zope as root, assuming you don't configure Zope to fly in the face of reason, and assuming you discount the possiblity of exacerbating other external vulnerabilities your system may have (which is a stupid thing to discount IMO), then no, Zope doesn't increase the possiblity of obtaining root privileges. -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy
Christian Tismer wrote:
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
Thats a good answer. Another one you might consider is, "2 liters" because there is no simple answer to that question.
There are people claiming that Zope opens a system to quite some level, others claim the opposite.
Ideally, Zope only opens the system to the extent the system administator allows it to. Resource limits, chroot jails, and so forth, are effective ways to de-fang many of the avenues available to zope users with the ability to instantiate dtml, script, and other such objects. Zope's ACLs also help an admin carve up their users into realms of trust.
Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"? And, pondering more on security, are these issues, if they exist, bounded to Zope itself, or becomes a system generally more "open" to attacks, after Zope was installed?
Generally, the more software you install, the more open to attack you are. If you don't need it, don't run it, and don't install it. Some Zope products may open up more avenues of exploit than others, thats why the admin should audit them before installing.
I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone.
No, its not a very simple question. If Zope was a small program with a single clear purpose, it might be. But Zope is a large framework with a multitude of directions. (A small program with a single clear purpose can not do what Zope does; let it be known I'm not suggesting Zope should be somehow packed into a small program with a single clear purpose. Broken up into several... perhaps, but thats a different thread.) Outside of the ideal world, unless extreme care is taken, software tends to have flaws with security ramifications. Last time I counted (March 1st.) there were 16 unaddressed issues in the Zope bug collector that had been marked as having security ramifications. Two of them are mine, and thus I feel confident in saying Zope is not as secure as it should or could be, but that if nothing else, the maintainers have been made aware of these shortcomings and that one can assume (if they should or not is a different matter) the issues will be taken care of. I will go on record as saying that, recently, response times to security related issues in the Zope2 tree have been disapointing. Construe from that what you will. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
My answer to this is: 1. Protecting yourself from your users: Zope fine grained acces control means that you can set up access restrictions that do exactly what you want and let user do what they need, and prevents them from doing what they should not. Obviously you can also make everybody do everything, so how secure a software is in this sense is not a measure of how secure your installation is, but of how secure it CAN be. In this sense Zope is VERY secure. 2. Protecting yourself from packet snooping: Zope doesn't have any encryption built-in, SSL needs external software to implement fro example. In this sense Zope can be MADE secure with some work, but is not secure at all out of the box. 3. Protecting yourself againt forceful entry: To my knowledge, nobody has cracked open a reasonably correctly configured Zope server yet. If this is because nobody has tried or nobody has suceeded, I wouldn't know. Security by obscurity does not help against the determined hacker, but it helps against script kids, and they are a more common problem. Zope is probably secure in this sense. 4. Protecting yourself against data loss: The ZODB is very resilient against crashes and data loss. Making a simple backup each day is plenty. Zope is VERY secure in this sense. 5. Protecting yourself against denial of service: Zope does not seem to crash if you send random data to it, and I have in logs seen attemps to overflow buffers and the like that obviously are attempt to crash or break in to other (MS) servers, without this affecting Zope at all. If you don't trust Zope in this, you can put Apache in front of it. In this sense Zope is again VERY secure. So all in all, Zope is a pretty good choice from this standpoint. I wouldn't use it without external SSL stuff if I were a bank, but otherwise I'm perfectly confident in the stability and security of Zope.
Lennart Regebro wrote:
5. Protecting yourself against denial of service: Zope does not seem to crash if you send random data to it, and I have in logs seen attemps to overflow buffers and the like that obviously are attempt to crash or break in to other (MS) servers, without this affecting Zope at all. If you don't trust Zope in this, you can put Apache in front of it.
In this sense Zope is again VERY secure.
No it isn't. (somewhere far in the distance Rainer Wolfcaststle is heard crying, "My RAM! The proxies, they do nothing!")
Jamie Heilman wrote:
In this sense Zope is again VERY secure.
No it isn't.
A statement like that without an argument is worthless in a discussion. You need to elaborate as we cannot read your mind and see what lies behind the statement. regards Max M
Max M wrote:
A statement like that without an argument is worthless in a discussion. You need to elaborate as we cannot read your mind and see what lies behind the statement.
My statement wasn't really aimed at you, sorry, I'm not playing fair. My statement was aimed at people who don't have to read my mind because they've been informed, and I'm making it in a public forum to be a pain the ass. I've already mentioned I have outstanding security related bugs in the collector, and as Toby noted I've been vocal on the value of process seperation and resource limits. This isn't a coincidence. Without properly configured resource limits, it is trivial to use an exposed Zope instance to exhaust host resources. This isn't entirely Zope's problem, this is usually an issue of misconfiguration. For example, until Zope 2.6, ZServer imposed no length limits on HTTP request headers. (These headers are read directly into memory, thus it was fairly easy to exhaust the memory of a host without resource limits.) When I found that out I reported it as a bug, and it was promptly addressed. (kudos) Now it could easily be argued, and I wouldn't be inclined to really disagree, that header length limits should be configured by the fronting server. What I didn't appreciate at the time is just how important a front-end proxy server is for Zope. If you expose Zope to a hostile network, it is mandatory. So now I don't consider this kind of thing a bug in Zope, unless Zope happens to make it possible to drastically amplify the effects of such an attack, (at which point crashing zope by running it into a resource limit becomes trivial) and a front-end proxy is unable or unlikely to thwart the attack. Zope's bug collector hides security related bugs until they are deemed worth of display by the controllers. Personally I think full disclosure is preferable to secrecy, but I'm willing to play by the rules laid down as long as I think the system is working for the general benefit of the community. You may have noticed I haven't been terribly secretive about recent cross site scripting or cache poisoning issues, and that can be attributed to, in part, my growing disastifaction with the system. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Jamie Heilman wrote Without properly configured resource limits, it is trivial to use an exposed Zope instance to exhaust host resources.
If this is a real risk for you, you should be using per-process limits to make sure that the host can't be completely destroyed. Sure, zope will fall over when it hits the limit, but that's better than taking out the whole host. Yes, the existing bugs should (and probably will) be addressed as they're found, but as a belt-and-braces kinda thing, limits are also useful.
Zope's bug collector hides security related bugs until they are deemed worth of display by the controllers. Personally I think full disclosure is preferable to secrecy, but I'm willing to play by the rules laid down as long as I think the system is working for the general benefit of the community. You may have noticed I haven't been terribly secretive about recent cross site scripting or cache poisoning issues, and that can be attributed to, in part, my growing disastifaction with the system.
That's really a separate issue that is a zope corp thing to address... Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Hi Jamie, I'm wondering if you might consider applying for checkin privileges. The host header issue that you've uploaded several patches for is a bonafide problem for some users, but I think that most people with checkin privs feel that it isn't sufficiently dangerous to the majority of users to take the time out to review all of your patches and vouch for them via a checkin (this might take a day or so to do). OTOH, if you could just check them in yourself, you would no longer feel disenfranchised. The process for obtaining checkin privileges is documented here: http://dev.zope.org/CVS/ContributorIntroduction HTH, - C On Thu, 2003-03-13 at 06:42, Jamie Heilman wrote:
Max M wrote:
A statement like that without an argument is worthless in a discussion. You need to elaborate as we cannot read your mind and see what lies behind the statement.
My statement wasn't really aimed at you, sorry, I'm not playing fair. My statement was aimed at people who don't have to read my mind because they've been informed, and I'm making it in a public forum to be a pain the ass.
I've already mentioned I have outstanding security related bugs in the collector, and as Toby noted I've been vocal on the value of process seperation and resource limits. This isn't a coincidence.
Without properly configured resource limits, it is trivial to use an exposed Zope instance to exhaust host resources. This isn't entirely Zope's problem, this is usually an issue of misconfiguration. For example, until Zope 2.6, ZServer imposed no length limits on HTTP request headers. (These headers are read directly into memory, thus it was fairly easy to exhaust the memory of a host without resource limits.) When I found that out I reported it as a bug, and it was promptly addressed. (kudos) Now it could easily be argued, and I wouldn't be inclined to really disagree, that header length limits should be configured by the fronting server. What I didn't appreciate at the time is just how important a front-end proxy server is for Zope. If you expose Zope to a hostile network, it is mandatory. So now I don't consider this kind of thing a bug in Zope, unless Zope happens to make it possible to drastically amplify the effects of such an attack, (at which point crashing zope by running it into a resource limit becomes trivial) and a front-end proxy is unable or unlikely to thwart the attack.
Zope's bug collector hides security related bugs until they are deemed worth of display by the controllers. Personally I think full disclosure is preferable to secrecy, but I'm willing to play by the rules laid down as long as I think the system is working for the general benefit of the community. You may have noticed I haven't been terribly secretive about recent cross site scripting or cache poisoning issues, and that can be attributed to, in part, my growing disastifaction with the system.
-- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Thursday 13 March 2003 2:33 pm, Chris McDonough wrote:
Hi Jamie,
I'm wondering if you might consider applying for checkin privileges.
Thats a good idea
The host header issue
Good catch on that bug btw,
that you've uploaded several patches for is a bonafide problem for some users, but I think that most people with checkin privs feel that it isn't sufficiently dangerous to the majority of users to take the time out to review all of your patches
I suspect most people with checkin privelidges dont know about this problem, because it wont have been sent to the public mailman list. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On Thu, 2003-03-13 at 10:26, Toby Dickenson wrote:
I suspect most people with checkin privelidges dont know about this problem, because it wont have been sent to the public mailman list.
True. I really don't know which set of committers gets the "security-related" emails from that collector. I do, somehow. Other folks at ZC do as well. If something really bad comes up, someone typically sounds the alarm and we put out a hotfix ASAP. I think this particular problem occurs in a sufficiently narrow set of circumstances that we didn't go into helmet fire mode on it (e.g. I think the consensus is it should be fixed in an upcoming release, but it doesn't require a hotfix). That said, this is a guess (and a judgement call), I haven't discussed it with anyone else. - C
I suspect most people with checkin privelidges dont know about this problem, because it wont have been sent to the public mailman list.
Perhaps an email can be sent out saying Issue number 1234. Temporarily restricted pending security review. http://url.to.get.it.if.you.are.logged.in Then, I'd be able to follow the link, authenticate, and read the issue. -- Steve Alexander
This is a good idea. I'll add an issue to the collector collector. - C On Thu, 2003-03-13 at 11:10, Steve Alexander wrote:
I suspect most people with checkin privelidges dont know about this problem, because it wont have been sent to the public mailman list.
Perhaps an email can be sent out saying
Issue number 1234. Temporarily restricted pending security review. http://url.to.get.it.if.you.are.logged.in
Then, I'd be able to follow the link, authenticate, and read the issue.
-- Steve Alexander
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Chris McDonough wrote:
I'm wondering if you might consider applying for checkin privileges.
I've considered it. I don't think you need anymore cooks, maybe just a few more recipes.
The host header issue that you've uploaded several patches for is a bonafide problem for some users, but I think that most people with checkin privs feel that it isn't sufficiently dangerous to the majority of users to take the time out to review all of your patches and vouch for them via a checkin (this might take a day or so to do).
Well then that either means I'm not explaining it well enough, or I'm wrong, or something. What I'm shooting for is some discussion of the issue, which to use bug 813 as an example, is why I asked for it to be made public. Even after going into more explicit detail on the zope list though I got exactly 0 followups, so I was starting to think people just didn't really care all that much. Thankfully this thread came along...
OTOH, if you could just check them in yourself, you would no longer feel disenfranchised.
I don't actually feel disenfranchised, just confused as to what kind of commitment to security ZC is making. My disapointment stems from my lack of ability to get any feedback on the bugs I've submitted. Its kinda happening now, but having to kick up dust to make it happen is less than ideal. I'm also worried about the amount of reported bugs versus the activity occuring to fix them. I understand many of them are probably "I did X and Y crashed, and gosh I think it might be a security problem in Z." without any analysis apart from random observation, which is sort of a pain in the ass to deal with, but they aren't visible, and thus I worry they aren't all like 493. (of which 494 is a public dupe <g>) -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
On Thu, 2003-03-13 at 22:09, Jamie Heilman wrote:
Chris McDonough wrote:
I'm wondering if you might consider applying for checkin privileges.
I've considered it. I don't think you need anymore cooks, maybe just a few more recipes.
We have many recipes already.
The host header issue that you've uploaded several patches for is a bonafide problem for some users, but I think that most people with checkin privs feel that it isn't sufficiently dangerous to the majority of users to take the time out to review all of your patches and vouch for them via a checkin (this might take a day or so to do).
Well then that either means I'm not explaining it well enough, or I'm wrong, or something. What I'm shooting for is some discussion of the issue, which to use bug 813 as an example, is why I asked for it to be made public. Even after going into more explicit detail on the zope list though I got exactly 0 followups, so I was starting to think people just didn't really care all that much. Thankfully this thread came along...
It's not that people don't care, it's that there's a lot of work to do, a limited amount of time to do it in, and people have to choose carefully what they apply themselves to. I'm sure you can understand this.
OTOH, if you could just check them in yourself, you would no longer feel disenfranchised.
I don't actually feel disenfranchised, just confused as to what kind of commitment to security ZC is making.
Zope is an open source product, the collector issues make their way to many folks outside ZC as well.
My disapointment stems from my lack of ability to get any feedback on the bugs I've submitted. Its kinda happening now, but having to kick up dust to make it happen is less than ideal.
I'm not sure how else to help you. The bug reports are appreciated, but we need folks to do the work.
I'm also worried about the amount of reported bugs versus the activity occuring to fix them. I understand many of them are probably "I did X and Y crashed, and gosh I think it might be a security problem in Z." without any analysis apart from random observation, which is sort of a pain in the ass to deal with, but they aren't visible, and thus I worry they aren't all like 493. (of which 494 is a public dupe <g>)
Which is why we want more cooks. If you don't want checkin privs, that's ok, but you'll need to be more patient. - C
On Thursday 13 March 2003 9:25 am, Lennart Regebro wrote:
5. Protecting yourself against denial of service: Zope does not seem to crash if you send random data to it, and I have in logs seen attemps to overflow buffers and the like that obviously are attempt to crash or break in to other (MS) servers, without this affecting Zope at all.
There is evidence that this is not true.
If you don't trust Zope in this, you can put Apache in front of it.
In this sense Zope is again VERY secure.
Zope is insecure Zope+Squid(or Apache or Pound)+OS resource limits+careful choice of products is secure (Note that I dont consider this a flaw in Zope.) -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On March 13, Lennart Regebro wrote:
2. Protecting yourself from packet snooping: Zope doesn't have any encryption built-in, SSL needs external software to implement fro example.
In this sense Zope can be MADE secure with some work, but is not secure at all out of the box.
Speaking of which, does anyone have any strategies for doing a combination HTTP/HTTP-S setup, ie, where anonymous requests are HTTP, and all authenticated requests are encrypted? Specifically, Zope has no way of knowing beforehand that access to a resource will throw an Unauthorized error, and when it does, it just sends a WWW-Authenticate header, and the browser retries the request with the supplied header. We want to enforce that passwords are never solicited without SSL. One way is probably to use CookieCrumbler and hack it to rewrite came_from so s/^http/https/. Is there a way that doesn't require hacking? a. -- Adrian van den Dries adriand@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au
On Fri, Mar 14, 2003 at 09:19:55AM +1100, Adrian van den Dries wrote:
On March 13, Lennart Regebro wrote:
2. Protecting yourself from packet snooping: Zope doesn't have any encryption built-in, SSL needs external software to implement fro example.
In this sense Zope can be MADE secure with some work, but is not secure at all out of the box.
Speaking of which, does anyone have any strategies for doing a combination HTTP/HTTP-S setup, ie, where anonymous requests are HTTP, and all authenticated requests are encrypted?
If you're front-ending with Apache, you could have a rewrite rule that would send an HTTP redirect if there are authentication credentials in the request. It still means one trip across the net with credentials in the clear. Not useful if you are using SSL for privacy but useful if you are using SSL for authenticity.
Specifically, Zope has no way of knowing beforehand that access to a resource will throw an Unauthorized error, and when it does, it just sends a WWW-Authenticate header, and the browser retries the request with the supplied header. We want to enforce that passwords are never solicited without SSL.
One way is probably to use CookieCrumbler and hack it to rewrite came_from so s/^http/https/. Is there a way that doesn't require hacking?
You could maybe wrap stuff in a method or object that will catch an Unauthorized error and return a HTTP redirect to a https:// URL. When the page is hit using HTTPS, don't bother checking. This simplest thing to do would be to do everything over SSL (anonymous or authenticated). I do this now with an apache non-SSL virtual host sending a redirect to the SSL virtual host with the same URI. -- Dave =============================================================== | <- You must be smarter than this stick to ride the Internet -Mike Handler ===============================================================
On Thursday 13 March 2003 5:21 am, Shane Hathaway wrote:
The only vulnerability would involve trusted users who want to vandalize Zope. So even though there have been many hotfixes, they are irrelevant--Zope is still secure. (Unless you can't trust your trusted users, which is a different problem.)
Of course you cant *completely* trust your trusted users. Thats why we have seperate user accounts, and seperate roles. IMO: Zope is sufficiently vulnerable to abuse from trusted users to justify concern. The normal zope development model is to consider normal python code as trusted - normal python code can do anything without security checks. Zope has many normal python methods that can be called by through-the-web code (after permission checking). In unix terms this is equivalent to having many setuid root programs. IMO concern can be justified without needing to find a specific exploit. From this point of view, Jamies advocacy of using Unix mechanisms to restrict this 'trusted' python code is valuable. On Thursday 13 March 2003 1:58 am, Jamie Heilman wrote:
I will go on record as saying that, recently, response times to security related issues in the Zope2 tree have been disapointing. Construe from that what you will.
It is hard to find time for security work among the feature rush of the cvs trunk, and without compromising the stability of the maintenance branch. Would there be any interest from other developers in addressing these potential security issues in a *fork* starting with the 2.6 maintenance branch? (reply-to set to zope-dev) -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On Thu, 13 Mar 2003, Toby Dickenson wrote:
On Thursday 13 March 2003 5:21 am, Shane Hathaway wrote:
The only vulnerability would involve trusted users who want to vandalize Zope. So even though there have been many hotfixes, they are irrelevant--Zope is still secure. (Unless you can't trust your trusted users, which is a different problem.)
Of course you cant *completely* trust your trusted users. Thats why we have seperate user accounts, and seperate roles.
IMO: Zope is sufficiently vulnerable to abuse from trusted users to justify concern. The normal zope development model is to consider normal python code as trusted - normal python code can do anything without security checks. Zope has many normal python methods that can be called by through-the-web code (after permission checking). In unix terms this is equivalent to having many setuid root programs. IMO concern can be justified without needing to find a specific exploit. From this point of view, Jamies advocacy of using Unix mechanisms to restrict this 'trusted' python code is valuable.
I agree with you in principle, but your choice of words leads an outsider to believe that a vulnerability in Zope's internal security model is a root exploit. The truth is that a vulnerability in Zope's internal security model can only "setuid" to the privileges of the owner of the Zope process, and root doesn't own the Zope process. On most systems, Zope is owned by an independent, restricted user. To get root privileges, the user would still have to make use of a root exploit outside Zope. Yes, Zope's internal security model is currently too fragile, since any product can break the barriers, but Zope 3 is working to deal with that. Shane
Jamie Heilman wrote: [snipped many good things]
Generally, the more software you install, the more open to attack you are. If you don't need it, don't run it, and don't install it. Some Zope products may open up more avenues of exploit than others, thats why the admin should audit them before installing.
Yes, I know. Carelessly written products can do quite much. I used Zope for half a year, intensively, and also wrote a database driver, so I know what it is about. Just wanted to get an update, since so much has happened since I stopped looking for mroe than a year. ...
No, its not a very simple question. If Zope was a small program with a single clear purpose, it might be. But Zope is a large framework with a multitude of directions.
I know. "simple question" was not meant seriously. :-) Simple to formulate, like "what is love".
(A small program with a single clear purpose can not do what Zope does; let it be known I'm not suggesting Zope should be somehow packed into a small program with a single clear purpose. Broken up into several... perhaps, but thats a different thread.)
This would interest me quite much, if it is possible to split this up into different small packages, which combine nicely. I fear I know the answer for the next few years already...
Outside of the ideal world, unless extreme care is taken, software tends to have flaws with security ramifications. Last time I counted (March 1st.) there were 16 unaddressed issues in the Zope bug collector that had been marked as having security ramifications. Two of them are mine, and thus I feel confident in saying Zope is not as secure as it should or could be, but that if nothing else, the maintainers have been made aware of these shortcomings and that one can assume (if they should or not is a different matter) the issues will be taken care of.
I will go on record as saying that, recently, response times to security related issues in the Zope2 tree have been disapointing. Construe from that what you will.
Do I read a bit of disappointment between the lines? If you compare Zope's bug paranoia with Python's, would you say Zope is a bit less concerned, or there are not enough people being concerned to get things resolved? Why I'm asking is simply because I'm concerned that there are no bugtraq entries for Zope, and I don't buy that this comes from Zope being bug-free. Maybe not enough people care about this, but if the hackers also don't care, why should I :-) I-know-I-shouldn't-have-said-that-at-all - ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
If you compare Zope's bug paranoia with Python's, would you say Zope is a bit less concerned, or there are not enough people being concerned to get things resolved?
I don't really know, I don't follow Python all that closely. Though due cgi.py's usage of tempfile.py I set my TMPDIR to a directory only writable by my zope process owner, and I don't see that changing until python 2.3 though I haven't read over the rewrite.
Why I'm asking is simply because I'm concerned that there are no bugtraq entries for Zope, and I don't buy that this comes from Zope being bug-free.
I don't think there's that many people actively auditing the source. All the bugs I've found haven't come from me looking for way a to do something malicious, they've come from me noticing bizzare behavior while trying to get something to work and just following up on it.
Maybe not enough people care about this, but if the hackers also don't care, why should I :-)
I don't know, why should you? I care because it used to be my job to care, now I can't seem to let the mentality go. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
On Wed, 2003-03-12 at 19:54, Christian Tismer wrote:
Dear Zope community,
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
There are people claiming that Zope opens a system to quite some level, others claim the opposite.
Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"?
And, pondering more on security, are these issues, if they exist, bounded to Zope itself, or becomes a system generally more "open" to attacks, after Zope was installed?
I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone.
I think the problem is that the question isn't really "simple", because the different configurations in which Zope is used vary so much. For instance, let me describe a configuration which is in production todday: - Zope is configured such that it listens for requests only on a single, non-routed interface. - Public access is mediated by a caching "reverse" proxy. - The user and group as which Zope runs in this setup hass extremely reduced privilegss: it has read access to Python, the standard Python libraries, the Zope sofware, and its configuration files; it has write access only to the "var" directory in which it keeps its database, PID, and log files. - Anonymous users in this Zope instance have only one permission, which allows them to view published content. They cannot create objects in the ZODB at all. - Content managers never log into this Zope instance at all; instead, they use a separate instance, behind the company's firewall, with an entirely different set of permissions; yet, the content is shared directly with the "public" site, via "mounted" storages. In this scenario, the Zope process itself has a very small vulnerability set: - The proxy shields Zope from most forms of DoS attacks (cleverly constructed query strings might still be able to get through). - Because the Zope instance uses Python's string handling facilities, it is not vulnerable to many of the "buffer overflow" attacks which plague C-based daemons. - If a user could gain control of the Zope process, the only scope for damage would be the ZODB itself. Now let me describe another configuraton, running in production now for years (one process in the cluster had an uptime of 400 days at a recent hardware-induced reboot): - Two Zope application servers run behind a load balancer and an Apache proxy (non-caching), serving requests against data in a shared storage server. - The server permits through-the-web registration, with minimal identity check (only a valid e-mail address. As of this writing, there are 18000+ user accounts. - Users of the site get a "member folder" where they can create templates, Python scripts, and content within the ZODB. Some minimal workflow exists, controlling basically whether the user's content is included in site searches. This configuration is perhaps the most vulnerable I can think of: nearly-anonymous users can create applications, using as much of Python as the through-the-web Python scripts allow. Yet, in the years this site has been running, it has suffered from only mild forms of abuse: - Malice-free templating triggered DoS-like bursts of activity (looping, or pathologically-nested acquisition). - Warez r00erz were using the site to serve ripped-off tarballs, before the site added upload filters which made the practice unprofitable. - Some users used the templating features to construct sub-sites which violated the terms of use for their accounts, which were eventually terminated. - Occasionally, the site sees bursts of DoS-like activity (which may be malicious, or may simply be incompetently-written spiders). The normal defense to such attacks is to block packets from their IPs (or ranges) at the border router. How could such a site not have been wrecked? I can offer a couple of hypotheses: - Trashing it hasn't been attractive enough to sufficiently determined blackhats. - Zope's restrictions on through-the-web code are mostly successful: in particular, such code can see only "white-listed" library modules, and has limited access to attributes and methods of objects in the object database.
thanks so much in advance -- chris
There *are* add-on products which can potentially increase the vulnerability of a Zope application, by expanding access to the kinds of modules which allow an attacker to "springboard" from Zope (Python's urllib, os, etc.). Zope has issued a number of "security advisories", accompanied by installable "hot-fix" products: http://www.zope.org/Products/Zope/hotfixes Note that almost all of these advisories relate to issues with "through- the-web" scripting / templating. Of the remaining set, one hotfix patched an underlying Python vulnerability (in cgi.py). Sites which do not permit untrusted users to authenticate have, by and large, not been exposed to these issues. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
On Wed, Mar 12, 2003 at 09:39:02PM -0500, Tres Seaver wrote:
Now let me describe another configuraton, running in production now for years (one process in the cluster had an uptime of 400 days at a recent hardware-induced reboot):
- Two Zope application servers run behind a load balancer and an Apache proxy (non-caching), serving requests against data in a shared storage server.
- The server permits through-the-web registration, with minimal identity check (only a valid e-mail address. As of this writing, there are 18000+ user accounts.
- Users of the site get a "member folder" where they can create templates, Python scripts, and content within the ZODB. Some minimal workflow exists, controlling basically whether the user's content is included in site searches.
Hmmm, I wonder what this site is. ;-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's GIRL ATHON! (random hero from isometric.spaceninja.com)
[Christian Tismer]
... I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone.
There may be a simple question hiding in this, but it's hard to find <wink>. You try: how secure is sendmail? how secure is ssh? how secure is Python? Answer those simple(?!) questions in the way you're looking for, and maybe someone can do the same wrt Zope. As is, you *appear* to be asking for a one-word summary of an encyclopedia. "Big" <wink>.
Tim Peters wrote:
[Christian Tismer]
... I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone.
There may be a simple question hiding in this, but it's hard to find <wink>.
You try: how secure is sendmail? how secure is ssh? how secure is Python? Answer those simple(?!) questions in the way you're looking for, and maybe someone can do the same wrt Zope. As is, you *appear* to be asking for a one-word summary of an encyclopedia. "Big" <wink>.
Hey, you're right. Maybe, by "simple question" I meant "short question", not necessarily easy to answer at all. :-) For the sysadmin's POV, I think it should be formulated like: If I install Zope, and I don't have the time to become a Zope guru, what are the newly accumulated risks for my system, if I use the default installation? The biggest fear would probably be a number of known exploits, and Joe Hacker just has to download some of "those tools", and the system is open. It appears that at least *that* is not the case. I think the answers given on the list were quite useful, thanks to you all! cheers - chris p.s.: sendmail? ssh? Python? Security exploits are discussed in the bugtraq list. I can find them all in the list archive. What about Zope? It is not in bugtraq. -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
[Christian Tismer]
... p.s.: sendmail? ssh? Python? Security exploits are discussed in the bugtraq list. I can find them all in the list archive. What about Zope? It is not in bugtraq.
The obvious conclusion is that no security hole has ever been discovered in Zope. Whether that's a *correct* conclusion I take no position on, just that it's the obvious conclusion <wink>.
I think the answers given on the list were quite useful, thanks to you all!
You're welcome. Don't forget that Zope's source is open, too: lots of eyeballs have scanned it, so the potentially dangerous modes of operation seem well-known in the community.
On 03/12/2003 07:54 PM, Christian Tismer wrote:
Dear Zope community,
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
There are people claiming that Zope opens a system to quite some level, others claim the opposite.
Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"?
Well, here's the way I read this. Let's say you're a system administrator and someone wants to add a service you've never heard of. Here's what you would ask to assess its security: - Is there any way this service can grant root privileges? If so, are there adequate protections? - Can this service do things to the server that are difficult to control, like fork bombs or lock starvation? - Can this service be hijacked to do unexpected things on the network (like assist in a DDoS attack or relay spam)? - Even if it can't hurt the server or other servers, does the service protect itself from vandalism, information theft, and DoS attempts? - Have there been a lot of security vulnerability patches for this service? I think this list is pretty comprehensive. I think if stock Zope provides satisfactory answers to all of these questions, we can legitimately call it secure. First, even if you run Zope as root, Zope drops root privileges as soon as it can. By the time it accepts requests, it can no longer do anything as root. The Zope internal security model is fully confined to the limitations of the owner of the Zope process. So stock Zope is secure in this regard. Second, certain features of modern kernels aren't quite mature, and if abused, these features can lead to a denial of service. Zope uses long-running Python threads, so it doesn't make much use of kernel services like forking and massive locking. (Other resources like RAM, CPU, and hard disk space are more mature and easier to control using ulimits, quotas, and partitions.) Stock Zope is secure in this regard. Third, Zope is designed to be a self-contained network service. Other than the internal SMTP relay service, stock Zope doesn't have a way to access services on other servers. In a way, this is a missing feature, but it also makes Zope unattractive as a potential DDoS relay node. As for relaying spam, the SMTP relay service is protected by Zope's security model. Only trusted users can send email. So if Zope's security model is secure, stock Zope is secure in this regard too. Fourth, Zope has its own security model independent of the system security that controls access to the Zope database, Python products, and the Python standard library. There have been mistakes in the internal security model before, but the mistakes only allowed already trusted users to do more than they should. I don't know of any security model breach ever that allowed untrusted or anonymous users to do something they shouldn't. And again, even if the internal security model is broken, Zope is still confined to the limitations of the owner of the process. So Zope is secure in this regard, as far as we know. Fifth, it is true that many hotfixes have been released for Zope, but Zope hotfixes are really quite different from patches to other products. Patches to other products tend to fix system-level things like buffer overflows, root exploits, temporary file race conditions, etc. Zope hotfixes operate at a much higher level than that, fixing only things that Zope cares about. If a system administrator installed an old version of Zope but ignored all the hotfixes ever released for Zope, the system would still be safe and Zope would still be protected against attacks by anonymous users. The only vulnerability would involve trusted users who want to vandalize Zope. So even though there have been many hotfixes, they are irrelevant--Zope is still secure. (Unless you can't trust your trusted users, which is a different problem.) So I think we can reliably say that stock Zope is secure. An insecure product, on the other hand, opens up many possibilities, but that ought to be the subject of a different discussion. Shane
So I think we can reliably say that stock Zope is secure. An insecure product, on the other hand, opens up many possibilities, but that ought to be the subject of a different discussion.
...and if we do have that discussion, can it please be on zope-dev@zope.org, and not cross-posted to both zope-dev@zope.org and zope3-dev@zope.org. Unless the discussion is about Zope 3 products, in which case it should be on only zope3-dev@zope.org. -- Steve Alexander
Christian Tismer schrieb:
Dear Zope community,
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
There are people claiming that Zope opens a system to quite some level, others claim the opposite.
Can someone please enlighten me and give me some details? Especially, are there some Zope products considered especially "insecure"?
And, pondering more on security, are these issues, if they exist, bounded to Zope itself, or becomes a system generally more "open" to attacks, after Zope was installed?
I don't mean to offend anybody by this, it is just a very simple question which I cannot answer alone.
thanks so much in advance -- chris
I think to be fair here we should compare Zope's security to the security of other similar tools, not only point out that there still are issues in Zope. It is extremely difficult to write secure web software that is at the same time highly interactive. If you want people to be able to do a lot with your system you will also have to open it up to some degree. My basic oppinion is that Zope is one of the most secure solutions for dynamic web applications. Some of the issues that have not been talked about in the previous postings: - Products that let you access the file system: There is a number of products (like LocalFS) that let you access the file system directly. While this is not always a problem one has to be extremely careful with those because they circumvent Zope's access limitations to the file system. Of course you are still restricted to the user Zope is running at ... - Products or methods that can use up a lot of resources: I can think of a couple of ways of using up most of the resources on a Zope system: - Using PIL (Python Imaging Library) without care: Let's say you offer an automatic image scaling tool to your users that can be called via a URL. Then it is relatively easy for an attacker to let PIL create huge images that might take several seconds to render and use up tens of megabytes of RAM. Doing this in a massive way will bring the server to a halt. There are similar exploits using other resource- intensive software, so this is just an example. Note that this is not a Zope design flaw, but a potential danger when being too careless in extending Zope. - Uploading huge files: This can effectively be handled by a proxy server (Apache can also limit most other DOS-related parameters quite efficiently) - Doing things that are perfectly allowed too frequently, like hammering the over-the-web registration tool with a robot: This has to be taken care of by the programmer. I'd guess that most of the servers out there (Zope or non-Zope) are not perfect in that respect. Again, Apache might help here. - Writing malicious code that "loops forever" etc. This is a part where Zope's security works quite well, but it is not perfect. There are no "infinite" loops or recursions because you'll eventually get stopped by Zope or Python. But I remember that I was able to write a three-liner in a (Script) Python that had a flaw and caused an enormous system load before it was terminated. The only way to stop this is careful coding. In a very public environment I'd limit the scripting available to site visitors to very simple tools like structured text. As soons as somebody untrusted can write code there is no way of preventing DOS-type attacks. Powerful tools are powerful. It's like guns: They can not be built to only kill the bad guys ... - Cross-scripting issues: I guess that some of those are still in the Zope Management Interface (which is not meant to be used by untrusted users in most cases), but Zope offers a lot of tools to make sure that it is hard to post malicious code in forums, attack Zope via URLs etc. For example there are quoting mechanisms in place, either automatic or easily applicable, that can be used to protect SQL strings, URLs, and text that is displayed on the site. The majority of exploits in PHP- or Perl-based solutions is in this domain. It is safe to say Zope is more secure than most other web application servers (protection against buffer overflows, limited access to the system's resources, very limited file system access, quoting mechanisms, secure SQL database access, very sophisticated internal security model), but Zope is not a firewall. If you don't take care there is some chance of DOS attacks. On the other hand I am quite positive that Zope is very secure in terms of preventing unauthorized access to the system (root exploits etc.). Joachim -- iuveno AG Joachim Werner _________________ Wittelsbacherstr. 23b 90475 Nürnberg joachim.werner@iuveno.de www.iuveno.de Tel.: +49 (0) 911/ 9 88 39 84
In article <3E708748.5050107@iuveno.de> you write:
- Cross-scripting issues:
I guess that some of those are still in the Zope Management Interface (which is not meant to be used by untrusted users in most cases), but Zope offers a lot of tools to make sure that it is hard to post malicious code in forums, attack Zope via URLs etc.
I've worked had to remove all those in the DTML code. I've not audited the rest of the python code that generates HTML directly (code that should be taken out and shot), but I think there are patches for those in the collector. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
On Thu, Mar 13, 2003 at 06:11:32PM +0100, Florent Guillaume wrote:
In article <3E708748.5050107@iuveno.de> you write:
- Cross-scripting issues:
I guess that some of those are still in the Zope Management Interface (which is not meant to be used by untrusted users in most cases), but Zope offers a lot of tools to make sure that it is hard to post malicious code in forums, attack Zope via URLs etc.
I've worked had to remove all those in the DTML code. I've not audited the rest of the python code that generates HTML directly (code that should be taken out and shot), but I think there are patches for those in the collector.
And Florent's patches came on top of my DTML pro-active anti-HTML-from- REQUEST-sourced-data changes that cause all outside strings to be HTML quoted if they could *possibly* be used to construct HTML tags. Some of my changes included taking out some of the directly-HTML-generating python code to be shot without trial. -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
On Thursday, March 13, 2003, at 11:54 AM, Christian Tismer wrote:
Dear Zope community,
please excuse my ignorance, but I am asked from time to time how secure or insecure Zope actually is, and I always have to say that I actually don't know.
From a sysadmin's point of view, it is roughly equivalent to Apache with CGI or PHP. The major differences are: - Zope's authentication & authorization systems are implicit in everything you write. It is harder to write insecure code than in PHP or CGI. - Anyone with ability to create dynamic content (dtml, python, zpt) can DOS your server. - You usually need to run Apache in front of Zope, which adds an additional attack point. -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/
participants (18)
-
Adrian van den Dries -
Anthony Baxter -
Chris McDonough -
Christian Tismer -
Dave Hall -
Florent Guillaume -
Jamie Heilman -
Joachim Werner -
Lennart Regebro -
Martijn Pieters -
Max M -
Paul Winkler -
Shane Hathaway -
Steve Alexander -
Stuart Bishop -
Tim Peters -
Toby Dickenson -
Tres Seaver