Re: [Zope] Regular expressions insecurity?
Mike Renfro wrote:
On Fri, Jan 17, 2003 at 03:36:25PM +0100, Tue Wennerberg wrote:
Mike Renfro wrote:
Basic summary: easy denial of service possibility if you have untrusted users.
But... If it's only a question of Denial of Service, how are regular expressions any different from python scripts. Surely, a site developer can simply make an infinite loop in his python script.
Here's my guess for the difference: whatever code is contained in the script is the developer's sole responsibility. However, a common regex usage would require input from an untrusted *user* (at least on a public site), and the developer can't necessarily plan for all possible inputs that a malicious user might stick in there.
I use regular expressions a lot, and the way I see it, no regexps would behave like that. So it isn't a problem. Also, it's widespread to use regular expressions in web sites written in Perl, and I've never heard of such a scenario occuring. I'm still puzzled as to why regular expressions are banned. -- Mvh. Tue Wennerberg Civilingeniør og Freelance Udvikler http://tuewennerberg.dk/ - tue@wennerberg.dk - (+45) 4043 6735
Tue Wennerberg wrote:
I'm still puzzled as to why regular expressions are banned.
"Banned" is a bit strong. I would say that they aren't enabled by default. It is certainly possible to allow them on your site by making your own security assertions for them. Cheers, Evan @ 4-am
Evan Simpson wrote:
Tue Wennerberg wrote:
I'm still puzzled as to why regular expressions are banned.
"Banned" is a bit strong. I would say that they aren't enabled by default. It is certainly possible to allow them on your site by making your own security assertions for them.
I agree, "banned" was too strong a word too use. English is not my native tongue, so please forgive me :-) But my point is, regular expressions ought to be enabled by default, because it's such a powerful feature, and the "insecurity" is present anyway. In fact, I don't even agree that there's a security issue at all, since you're forced to trust your script developer anyway. Regards, Tue Wennerberg Civilingeniør og Freelance Udvikler http://tuewennerberg.dk/ - tue@wennerberg.dk - (+45) 4043 6735
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Tue Wennerberg Sent: Saturday, January 18, 2003 8:23 AM To: zope@zope.org Subject: Re: [Zope] Regular expressions insecurity?
Mike Renfro wrote:
On Fri, Jan 17, 2003 at 03:36:25PM +0100, Tue Wennerberg wrote:
Mike Renfro wrote:
Basic summary: easy denial of service possibility if you have untrusted users.
But... If it's only a question of Denial of Service, how are regular expressions any different from python scripts. Surely, a site developer can simply make an infinite loop in his python script.
Here's my guess for the difference: whatever code is contained in the script is the developer's sole responsibility. However, a common regex usage would require input from an untrusted *user* (at least on a public site), and the developer can't necessarily plan for all possible inputs that a malicious user might stick in there.
I use regular expressions a lot, and the way I see it, no regexps would behave like that. So it isn't a problem. Also, it's widespread to use regular expressions in web sites written in Perl, and I've never heard of such a scenario occuring.
I'm still puzzled as to why regular expressions are banned.
There was a discussion of this months ago. There are, IIRC, two big answers. 1) It's easy to write a regexp that sucks down time, above and beyond what you would expect. Since Zope is often used as a general CMF for non technical people, exposing regexes is a bad idea (I don't buy this answer myself...) 2) The python regex package is in C and no one has written the security wrapping code that Zope requires. I'm fuzzy on the details but this answer makes a lot more sense. Thus the answer is most likely that it is not exposed because no one got around to it. Since the security risk is pretty small and you can easily expose it yourself, I don't think there is much pressure to fix the problem for real.
Thank you for your answers. Charlie Reiman wrote:
There was a discussion of this months ago. There are, IIRC, two big answers.
1) It's easy to write a regexp that sucks down time, above and beyond what you would expect. Since Zope is often used as a general CMF for non technical people, exposing regexes is a bad idea (I don't buy this answer myself...)
2) The python regex package is in C and no one has written the security wrapping code that Zope requires. I'm fuzzy on the details but this answer makes a lot more sense.
Well yes, if regular expressions were a security risk. This seems to be the general notion, but can anyone actually give an example?
Thus the answer is most likely that it is not exposed because no one got around to it. Since the security risk is pretty small and you can easily expose it yourself, I don't think there is much pressure to fix the problem for real.
Guess not. -- Mvh. Tue Wennerberg Civilingeniør og Freelance Udvikler http://tuewennerberg.dk/ - tue@wennerberg.dk - (+45) 4043 6735
On Tue, Jan 21, 2003 at 09:54:59PM +0100, Tue Wennerberg wrote:
2) The python regex package is in C and no one has written the security wrapping code that Zope requires. I'm fuzzy on the details but this answer makes a lot more sense.
Well yes, if regular expressions were a security risk. This seems to be the general notion, but can anyone actually give an example?
No, that's not the point of 2) above. The point is that *any* module you import in zope ttw code must have certain security assertions, or you'll be denied access when you try to run the script. Allowing re to be imported would require writing a python wrapper to the re module (which is in C), and adding these security assertions to the wrapper. Nobody has taken the time to do this and post it publically. It doesn't matter if the module is deemed a security risk or not. No security assertions? Import is not allowed except in External Methods and filesystem Products. No exceptions. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PYSCHOMETRIC JUDO SKORPION! (courtesy of isometric.spaceninja.com)
Paul Winkler wrote:
The point is that *any* module you import in zope ttw code must have certain security assertions, or you'll be denied access when you try to run the script. Allowing re to be imported would require writing a python wrapper to the re module (which is in C), and adding these security assertions to the wrapper. Nobody has taken the time to do this and post it publically.
It doesn't matter if the module is deemed a security risk or not. No security assertions? Import is not allowed except in External Methods and filesystem Products. No exceptions.
Excellent! Thank you for your precise answer! That's the piece of information I didn't have! Regards, Tue Wennerberg Civilingeniør og Freelance Udvikler http://tuewennerberg.dk/ - tue@wennerberg.dk - (+45) 4043 6735
participants (4)
-
Charlie Reiman -
Evan Simpson -
Paul Winkler -
Tue Wennerberg