Resolved security-related collector issues for the public?
Hi, there were several security-related fixes in the collector (and the collector-mailing-list) in the last days. Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc. Lots of security-stuff is fixed now, but I don't think that all people will migrate their servers as soon as possible (due to limited time, the experience of the Zope-2.6.3-"desaster", vacations, etc.pp.). With all the mentioned security-exploits in the collector out there, the probability of attacks will rise. And I don't think that this will shed a "good light" on Zope. My proposal: Can we have a delay for making security-related fixes public? Just a month or two or so... Cheers, Maik
Maik Jablonski wrote:
Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc.
Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough.
Lots of security-stuff is fixed now, but I don't think that all people will migrate their servers as soon as possible (due to limited time, the experience of the Zope-2.6.3-"desaster", vacations, etc.pp.).
Sure, thats true of every security hole.
With all the mentioned security-exploits in the collector out there, the probability of attacks will rise. And I don't think that this will shed a "good light" on Zope.
meh. Good, bad, its irrelevant, but you can't pretend there weren't problems and expect anyone with a shred of a clue to take you seriously. If you want to establish trust, you can be honest with your community, or you can do a lot of hand waving trying to cover things up and make yourself look even worse.
My proposal: Can we have a delay for making security-related fixes public? Just a month or two or so...
Every hole thats been fixed has been publically known and detailed for well over 4 months at the latest, with the exceptions of: 615 & 1154 - sessioning machinery was losing security context 924 - object properties stored as unprotected mutables All the unrestricted operations in RestrictedPython that were found as a result of ZC's security audit. (And possibly the unicode crashing issue, which I think got discussed on a public list or something fairly recently.) Delays are pointless. The broken sessioning machinery was sitting in the collector for a year and 3 months. During that time 2 different people uncovered the issue (presumebly) independantly, and reported it. How many uncovered it and didn't report it? How exactly was ZC supposed to release a new version of Zope with the fixes but at the same time not divulge the nature of the security flaws? Release an obsfucated binary distribution and say "Trust Us"? That doesn't sound very much like open source. -- 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
Hi Jamie, Jamie Heilman wrote:
Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. ... How exactly was ZC supposed to release a new version of Zope with the fixes but at the same time not divulge the nature of the security flaws? Release an obsfucated binary distribution and say "Trust Us"? That doesn't sound very much like open source.
In the past we had something like Hotfixes for security problems... Easy to install for the average administrator and that's it. I can check out the current Zope from a CVS... So getting security fixes is no problem for me. But I'm not an average Zope-Admin or -User. There are many admins / users out there who aren't able to do this (maybe they should learn it, but that's another point). Installing Zope 2.6.3 was a big mess (even renaming in the ZMI was broken) and most people rolled back to 2.6.2. Some people run even 2.5.1 (lots of Debian-Users etc.). If we don't have a easy-to-install-security-fix for such people (or a so called "stable" release, which works out of the box) we should a little bit cautious about releasing exploits. That's my point... Cheers, Maik
Maik Jablonski wrote:
There are many admins / users out there who aren't able to do this (maybe they should learn it, but that's another point). Installing Zope 2.6.3 was a big mess (even renaming in the ZMI was broken) and most people rolled back to 2.6.2. Some people run even 2.5.1 (lots of Debian-Users etc.).
Debian users who continue to use the 2.5.1 packages are being done an injustice, I agree, and its too bad, but the Debian security policy fails when a maintainer takes on a package they can't keep up with and the security team isn't able to step in and cover for them. It happens, the answer is usually to either find a new maintainer who can keep up, or remove the package from Debian. One of Debian's strengths though is that they don't hide this information, users are encouranged to review the bug tracking system to get a feel for a package's relative stability and weigh the risks on their own.
If we don't have a easy-to-install-security-fix for such people (or a so called "stable" release, which works out of the box) we should a little bit cautious about releasing exploits. That's my point...
So you want to offer aide to the people who've bitten off more than they can chew, and your proposed solutions seem to be either: a) provide easy-to-swallow security fixes & timely vulnerability disclosure b) provide neither Given that ZC clearly doesn't have the resources available to do (a), irrespective of if its even technically feasible, we can rule it out. And (b), well (b) just screws everybody. Exploits are a byproduct of understanding the vulnerability, they're a natural part of experimentation and learning. You usually can't discuss a vulnerabilty without implying the exploit. If you really want to help people who can't help themselves, offer education, not censorship in the guise of protection. -- Jamie Heilman http://audible.transient.net/~jamie/ ...and no, I don't support the War On Terror.
Jamie Heilman wrote Given that ZC clearly doesn't have the resources available to do (a), irrespective of if its even technically feasible, we can rule it out. And (b), well (b) just screws everybody. Exploits are a byproduct of understanding the vulnerability, they're a natural part of experimentation and learning. You usually can't discuss a vulnerabilty without implying the exploit. If you really want to help people who can't help themselves, offer education, not censorship in the guise of protection.
Worse yet, hiding the security bugs mean that other people who might be motivated to supply fixes are unaware of the issue and cannot help. I'd be +1 on exposing the security bugs - maybe after 2 weeks so that critical security flaws have a chance to be fixed immediately. But it should be an automatic thing, not something that requires manual intervention. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Wed, 21 Jan 2004 16:16:15 -0800 Jamie Heilman <jamie@audible.transient.net> wrote:
Maik Jablonski wrote:
There are many admins / users out there who aren't able to do this (maybe they should learn it, but that's another point). Installing Zope 2.6.3 was a big mess (even renaming in the ZMI was broken) and most people rolled back to 2.6.2. Some people run even 2.5.1 (lots of Debian-Users etc.).
Debian users who continue to use the 2.5.1 packages are being done an injustice, I agree, and its too bad, but the Debian security policy fails when a maintainer takes on a package they can't keep up with and the security team isn't able to step in and cover for them. It happens, the answer is usually to either find a new maintainer who can keep up, or remove the package from Debian. One of Debian's strengths though is that they don't hide this information, users are encouranged to review the bug tracking system to get a feel for a package's relative stability and weigh the risks on their own.
ZC has developed (thanks largely to Tres) a patch-set against 2.6 for the security fixes (and one can be regenerated from cvs as well, but the patches are better segregated). These could in theory be used as a basis for a patch set against 2.5.1. Saying it would be a large, difficult task to effectively backport the changes to 2.5 is an understatement, but it could be done. The change-set for 2.6 is Python 2.1 compatible, so at least you don't have to contend with that. Selectively backporting only certain fixes, that affect the widest range of sites, would be much easier to consider. This could mean some of the more invasive and tricky fixes, such as the ones for vulnerabilities in untrusted code, which IMO are really only a concern in a small minority of sites, could be skipped for a 2.5 backport. -Casey
Maik Jablonski wrote at 2004-1-21 23:42 +0100:
... If we don't have a easy-to-install-security-fix for such people (or a so called "stable" release, which works out of the box) we should a little bit cautious about releasing exploits. That's my point...
Almost all the issues covered by Zope 2.6.3 are irrelevant to the "normal" Zope installation (e.g. whether or not someone gets a binding for "context/container" while he does not have the object access permission). I think only the "cross scripting exploits" may be a real problem for "normal" installations. Their fix would probably have broken few sites... -- Dieter
Maik Jablonski wrote:
Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc.
Jamie Heilman wrote: Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough.
As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled. *Getting to that point* is what I'm afraid of :) There are pretty widely varying opinions on this, and historically as a community we've not yet found a good process to really resolve issues when there isn't a clear majority opinion. At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it. While we at ZC try very hard to strike a delicate balance between transparency and risk management, doing so on a case-by-case basis is tough and there will *always* be some who disagree with the course chosen, no matter what it is. All in all, I think we'd better off having 'The Rules' regarding security reports, and working to make sure that we are all consistent in following them. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Hi Brian, Brian Lloyd wrote:
As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled.
My intent was not flaming anyone... Sorry for that. I just tried to take the voice of the "average" Zope-Admin (installs Zope from a recent stable release, waits for the security-maintainers of distros to get security patches etc.).
At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it.
Very good idea...:) If all Zope-Admins can read before an installation: "Security exploits will be exposed to the public as soon as they're resolved in the CVS" everyone will & should run Zope out of CVS. My point was: Give people a chance to react on exposed security flaws. The statement above will do that because people should be prepared...:) Cheers, Maik
Brian Lloyd wrote:
As the person who unfailingly gets flamed no matter which way the decisions leans :), I think we are probably at a point where we should have an official, documented and community-agreed-to policy on how these kinds of things will be handled.
My intent was not flaming anyone... Sorry for that. I just tried to take the voice of the "average" Zope-Admin (installs Zope from a recent stable release, waits for the security-maintainers of distros to get security patches etc.).
Sorry, I should have been more clear. I didn't mean to imply that your or Jamie's notes were flames (they're definitely not), just that I'd been singed in the past ;)
At a minimum, having a clear and documented policy would provide the benefit of 'no surprises' - if you disagree with the policy, or some aspect of it, you would at least be able to plan around it.
Very good idea...:) If all Zope-Admins can read before an installation: "Security exploits will be exposed to the public as soon as they're resolved in the CVS" everyone will & should run Zope out of CVS.
...or will decide that doing so is unreasonable and use something else instead :( Note that I'm not necessarily criticizing that particular policy, just pointing out that _any_ policy will have some upside and some downside. The challenge will be coming to agreement on a policy with the right balance that everyone can live with. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
...or will decide that doing so is unreasonable and use something else instead :( Note that I'm not necessarily criticizing that particular policy, just pointing out that _any_ policy will have some upside and some downside. The challenge will be coming to agreement on a policy with the right balance that everyone can live with.
How about something along the lines of: - Development team only disclosure for the first x days (2 to 7 days is the maximum here I would think), in order to develop a workaround/patch. - Full disclosure after that, along with a published patch, hotfix or workaround. Other recommendations: - Increase the number of people who have access to the security section of the collector, to increase the chance that it will be discussed. - Form a closed security list for discussing such things amongst selected developers, away from the general public gaze (does such a thing already exist?) At some stage the sysadmin has to take responsibility for the packages they are using. I tend to believe, as almost certainly most of the security community does, that not all crackers are just script-kiddies waiting for an exploit. Lets face facts -- if someone is reporting an exploitable hole, anyone else (white/black/grey hat) could have also found it. I for one would love to know things like: Jamie Heilman wrote:
Clemens Robbenhaar wrote:
malicious Python Scripts on my site (I guess , and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free
Actually... unless you've altered the ZMI and HelpSys, you do use dtml-tree ...and HelpSys is publically traversable by default.
Anyone else spot the irony in the situation that _all_ the available security holes are available to a user who cracks the Zope collector site? --Richard
On Fri, Jan 23, 2004 at 09:45:43AM +1300, Richard Waid wrote:
Brian Lloyd wrote:
...or will decide that doing so is unreasonable and use something else instead :( Note that I'm not necessarily criticizing that particular policy, just pointing out that _any_ policy will have some upside and some downside. The challenge will be coming to agreement on a policy with the right balance that everyone can live with.
How about something along the lines of:
- Development team only disclosure for the first x days (2 to 7 days is the maximum here I would think), in order to develop a workaround/patch.
- Full disclosure after that, along with a published patch, hotfix or workaround.
OK, but what if there is no patch, hotfix, or workaround ready after 2-7 days? Some of these bugs have taken much longer. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PSUEDO LIGHTNING FRED! (random hero from isometric.spaceninja.com)
Paul Winkler wrote:
On Fri, Jan 23, 2004 at 09:45:43AM +1300, Richard Waid wrote:
How about something along the lines of:
- Development team only disclosure for the first x days (2 to 7 days is the maximum here I would think), in order to develop a workaround/patch.
- Full disclosure after that, along with a published patch, hotfix or workaround.
OK, but what if there is no patch, hotfix, or workaround ready after 2-7 days? Some of these bugs have taken much longer.
I think we need to be looking at _why_ the bugs have taken much longer. Is it strictly lack of resources? Security fixes, generally, shouldn't come in batches of 10 (or whatever) because, even if they're related, it makes testing the critical-security-patch-that-needs-to-be-applied-right-now extremely difficult for almost everyone. --Richard
On Wednesday 21 January 2004 03:21 pm, Jamie Heilman wrote:
Hiding the bugs doesn't avoid anything, it just leaves zope administrators helpless in the dark. I'm not going to rehash the arguments for and against full dislosure, but seriously--don't delude yourself into thinking that a problem goes away if you shut your eyes tightly enough.
Hear, hear! Consider also the position of someone who writes their own product code -- if potential exploits are know to exist with specific Zope functionality, it may be desireable to make design changes to compensate. Or at least, we know to pass that information on to users of our products. Not knowing puts us in a very uncertain position -- which I think is far worse for Zope's reputation than any specific set of known defects. What's more, that reputation may rub off on the rest of us. ;-) "Uncertainty" is the "U" in "FUD", remember. Cheers, Terry
[...]
there were several security-related fixes in the collector (and the collector-mailing-list) in the last days. Normaly security-related stuff is not visible for the public... and this seems to be good to avoid exploits etc.
At least for the resolved issues the fixed are public available from the CVS (maybe even together with log messages). Sufficiently skilled people thus can reconstruct the security issues from the changes; I feel there is no point for hiding them any longer. On the other hand admins may be less pressed to upgrade if they look at the current available list of fixes and find none which hurts them in their setup ... for example I do not have untrusted users able to write malicious Python Scripts on my site (I guess ;-), and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free to blow my site with one of the not yet published issues. my 2 cents, Clemens btw: it does not look like either zope.org nor zope.com has been upgraded yet? The find-support still looks quite public ...
Clemens Robbenhaar wrote:
malicious Python Scripts on my site (I guess ;-), and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free
Actually... unless you've altered the ZMI and HelpSys, you do use dtml-tree ...and HelpSys is publically traversable by default. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Jamie Heilman writes:
Clemens Robbenhaar wrote:
malicious Python Scripts on my site (I guess ;-), and I do not use DTML or some Tree-stuff -- thus I did not upgrade yet, and You may feel free
Actually... unless you've altered the ZMI and HelpSys, you do use dtml-tree ...and HelpSys is publically traversable by default.
Thanks for the clarification. I just tried to argue from a rather ignorant point of view ... I could argue some more about why these issues look not so dangerous to me, but even if I try hard, I cannot be so ignorant ;) Actually I only tried to point out that if someone would tell me there is another yet not published issue that would allow to read the password of my users TTW or the like, this would make me upgrade even in very ignorant mode. However when obscuring these issue this will ignorant (or just busy) admins not help a lot; they will upgrade after these issues are published, not after the fixes are released ... meanwhile black hats checking with the CVS may have their exploits applied already. About the current discussion of a security (non-)disclosure policy: I would be happy with a policy which makes security issues public if a fix from the public CVS is available. (Well, I am running Zope form the CVS, so my position is maybe a little biased ;-) Cheers, Clemens
Maik Jablonski wrote at 2004-1-21 21:20 +0100:
... My proposal: Can we have a delay for making security-related fixes public? Just a month or two or so...
-1 Most of the potential exploits have rather strict requirements (such as creation of executable content by untrusted users). Thus, few installations are really affected. At least I will not upgrade software when I get only a vague indication about some security fixes (without a clear indication what security issues are solved). -- Dieter
participants (10)
-
Anthony Baxter -
Brian Lloyd -
Casey Duncan -
Clemens Robbenhaar -
Dieter Maurer -
Jamie Heilman -
Maik Jablonski -
Paul Winkler -
Richard Waid -
T H