Thread: RE: [mod-security-users] mod_security causing Apache 1.3.33 to ha ng
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
mod-security-users
|
From: Servedio, A. (Matrix) <All...@ic...> - 2006-01-11 20:04:55
|
Just getting ready to... I am working with Ivan on it now. --------------------------------------------------- Allen Servedio Internet Developer (E-Commerce) Matrix Resources Consultant --------------------------------------------------- -----Original Message----- From: Christopher Murley [mailto:mu...@to...] Sent: Wednesday, January 11, 2006 3:01 PM To: Servedio, Allen (Matrix) Cc: 'mod...@li...' Subject: RE: [mod-security-users] mod_security causing Apache 1.3.33 to ha ng Did you run an strace on the apache process to see where it's hanging? -- Regards, -Chris _______________________________________________ Christopher Murley Network Administrator TownNews.Com 800.293.9576 Servedio, Allen (Matrix) said: > Hi, > > I compiled it with: > /apachehome/bin/apxs -cia mod_security.c > > Against and already compiled Apache (so, SSL was already compiled into > it). > > The above made a shared object in my libexec that I included with the > LoadModule (also did the AddModule entry as specified in your install > instructions). > > Yeah, I agree with you on the redirect. The reason that I just did the > root > like that is that this actually handles LOTS of domains. So, I thought > just > sending them back to the root was the safest way to ditch their parameters > but not give them an ugly error page. Is there a better way to do that? > > Thanks, > Allen > > --------------------------------------------------- > Allen Servedio > Internet Developer (E-Commerce) > Matrix Resources Consultant > --------------------------------------------------- > > > -----Original Message----- > From: Ivan Ristic [mailto:iv...@we...] > Sent: Wednesday, January 11, 2006 2:47 PM > To: Servedio, Allen (Matrix) > Cc: 'mod...@li...' > Subject: Re: [mod-security-users] mod_security causing Apache 1.3.33 to > hang > > Servedio, Allen (Matrix) wrote: >> Hi, >> >> I am new to using mod_security so there is a high probability that I >> messed something up with my configuration. But, I am able to get Apache >> to hang (consistently) while using mod_security by posting the form >> below (it is from a security scanning tool, in case the values look >> fishy :-) ). I would appreciate any insight as to what is causing this >> to hang. If I remove mod_security the same request passes through just > fine. > > I am unable to re-create the problem here (1.3.3 + mod_ssl 2.8.22, > running on Debian 3.1). > > Did you compile mod_security before or after mod_ssl installation? > mod_ssl for Apache 1.3.x actually patches the Apache source code and > changes the API? Many modules work after the patch on Linux but > I don't know about Solaris. > > >> SecFilterDefaultAction "deny,log,redirect:/" > > Strictly speaking redirects should be supplied with a full > URL. For example: redirect:http://www.example.com/ However, > I notice that even / works and redirects the user to the root > of the web site. > > There's nothing unusual in your configuration. > > -- > Ivan Ristic, Technical Director > Thinking Stone, http://www.thinkingstone.com > Tel: +44 20 8141 2161, Fax: +44 87 0762 3934 > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > > |
|
From: Ivan R. <iv...@we...> - 2006-01-11 20:59:40
|
Servedio, Allen (Matrix) wrote: > Just getting ready to... I am working with Ivan on it now. We didn't get to run truss (Allen did not have root on the box) but we narrowed it down pretty much to a problem in the Apache 1.3.x regular expression library. After changing the rule 'SecFilter "<(.|\n)+>" id:1002' to 'SecFilter "<.+>" id:1002' Apache did not hang any more. I have seen a similar problem once before, when I encountered a problem with Apache 2.x on Windows. It turned out to be a PCRE bug which manifested only on Windows because of the smaller stack size. If I recall correctly PCRE uses recursion for subexpressions internally, which leads to stack space consumption when the regex is applied to a long string. I think this is pretty much the same problem. Other modules that use regular expressions would probably suffer too. One solution is to avoid using subexpressions. Another might be to compile mod_security against PCRE (as far as I know the problem I reported was fixed a long time ago). -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com Tel: +44 20 8141 2161, Fax: +44 87 0762 3934 |
|
From: Tom A. <tan...@oa...> - 2006-01-11 23:05:24
|
Ivan Ristic wrote: > Windows because of the smaller stack size. If I recall > correctly PCRE uses recursion for subexpressions internally, > which leads to stack space consumption when the regex > is applied to a long string. For performance reasons, all regular expressions should be simplified as much as possible. Under the wrong circumstances, they can end up using lots of resources. For instance, expressions should be greedy whenever possible. The expression /<.+>/ will match "<head>" but will also search "<head> blah blah blah blah blah ..." until the end of the string to determine if the ">" is a part of the "." or not. It will also match "<head><title>HTML Injection Attack</title></head>" even though it would be sufficient to stop at "<head>" if you're just trying to reject HTML tags of any kind. So a more efficient version that prevents all kinds of recursive backtracking would be the greedy one /<.+?>/. But still, any filter that looks for one or two characters followed by ".+" or even ".+?" is going to be a likely resource hog during false positives. To cut down on this, try to add as much detail to an expression as possible. Using character classes to reduce the set of characters that will match can both cut down on false positives and also significantly reduce the recursion on each string. For instance, if an HTML tag cannot start with a number, then using the expression /<\s*[^\d].+?>/ will prevent the regex engine from searching a term such as "if x < 5, then z = 0 blah blah blah...." all the way to the end of the string. We've added more detail before the ".+?" part. This might be a bad example since most HTML engines will just ignore a number at the beginning of a tag, but then again, an HTML tag -- being an enclosure of just about any size string -- is just too fungible to efficiently identify and flag with a filter directive anyway. Better instead would be to sanitize your input so that HTML tags are made impossible by escaping the tag symbols themselves. But you can't just do this for every input ever passed into Apache, as some maybe shouldn't be mutilated in this way if they're ultimately never going to be displayed on a web page. Ideally, the script that handles this input should do its own sanitizing. I'm not sure if you can use mod_security to do this, but maybe you can try something like: SecFilterSelective THE_REQUEST "vulnerable-script-name" chain SecFilterSelective ARG_SANITIZEME "(<|>)" "exec:html_escape.pl" But I don't think the exec'd script gets passed the info or inserts anything back into the string. Ideally "html_escape.pl" would be passed the "ARG_SANITIZEME" content on STDIN and then mod_security would replace "ARG_SANITIZEME" with the output of "html_escape.pl". That would be a true external filter, similar to how procmail works. Ivan, correct me if I'm wrong in saying that you can't do using mod_security what I'm suggesting would be the right technique. Actually, ideally you could do this: SecFilterSelective THE_REQUEST "vulnerable-script-name" chain SecFilterSelective ARG_SANITIZEME s/</</ SecFilterSelective ARG_SANITIZEME s/>/>/ But that too wouldn't work in mod_security I believe. Is this something that could be added in future versions? Or maybe even a new directive specifically for html escaping input? Something like: SecFilterSelective THE_REQUEST "vulnerable-script-name" chain SecFilterHTMLEscape ARG_SANITIZEME I think it would be extremely useful to be able to modify request content in this way rather than just flagging it. Tom |
|
From: Ryan B. <rcb...@gm...> - 2006-01-12 02:27:57
|
Sounds like you want the functionality of the Apache mod_ext_filters ( http://httpd.apache.org/docs/2.0/mod/mod_ext_filter.html) integrated into mod_security so that it can change data within the request, correct? That would be nice. The closest that you can get in the meantime is to use either mod_rewrite or the new setenv mod_security action to identify and ta= g a request and then use the ENV triggering of mod_ext_filters to manipulate the inbound/outbound data. I have done with with some success. From my experience, it works pretty good for manipulating the payload (outbound html) but can be unstable if you set the "ftype=3D" mod_ext_filter setting = and start monkeying around with the HTTP headers. -- Ryan C. Barnett Web Application Security Consortium (WASC) Member CIS Apache Benchmark Project Lead SANS Instructor: Securing Apache GCIA, GCFA, GCIH, GSNA, GCUX, GSEC Author: Preventing Web Attacks with Apache On 1/11/06, Tom Anderson <tan...@oa...> wrote: > > Ivan Ristic wrote: > > > Windows because of the smaller stack size. If I recall > > correctly PCRE uses recursion for subexpressions internally, > > which leads to stack space consumption when the regex > > is applied to a long string. > > For performance reasons, all regular expressions should be simplified as > much as possible. Under the wrong circumstances, they can end up using > lots of resources. For instance, expressions should be greedy whenever > possible. The expression /<.+>/ will match "<head>" but will also > search "<head> blah blah blah blah blah ..." until the end of the string > to determine if the ">" is a part of the "." or not. It will also match > "<head><title>HTML Injection Attack</title></head>" even though it would > be sufficient to stop at "<head>" if you're just trying to reject HTML > tags of any kind. So a more efficient version that prevents all kinds > of recursive backtracking would be the greedy one /<.+?>/. > > But still, any filter that looks for one or two characters followed by > ".+" or even ".+?" is going to be a likely resource hog during false > positives. To cut down on this, try to add as much detail to an > expression as possible. Using character classes to reduce the set of > characters that will match can both cut down on false positives and also > significantly reduce the recursion on each string. For instance, if an > HTML tag cannot start with a number, then using the expression > /<\s*[^\d].+?>/ will prevent the regex engine from searching a term such > as "if x < 5, then z =3D 0 blah blah blah...." all the way to the end of > the string. We've added more detail before the ".+?" part. > > This might be a bad example since most HTML engines will just ignore a > number at the beginning of a tag, but then again, an HTML tag -- being > an enclosure of just about any size string -- is just too fungible to > efficiently identify and flag with a filter directive anyway. Better > instead would be to sanitize your input so that HTML tags are made > impossible by escaping the tag symbols themselves. But you can't just > do this for every input ever passed into Apache, as some maybe shouldn't > be mutilated in this way if they're ultimately never going to be > displayed on a web page. Ideally, the script that handles this input > should do its own sanitizing. I'm not sure if you can use mod_security > to do this, but maybe you can try something like: > > SecFilterSelective THE_REQUEST "vulnerable-script-name" chain > SecFilterSelective ARG_SANITIZEME "(<|>)" "exec:html_escape.pl" > > But I don't think the exec'd script gets passed the info or inserts > anything back into the string. Ideally "html_escape.pl" would be passed > the "ARG_SANITIZEME" content on STDIN and then mod_security would > replace "ARG_SANITIZEME" with the output of "html_escape.pl". That > would be a true external filter, similar to how procmail works. Ivan, > correct me if I'm wrong in saying that you can't do using mod_security > what I'm suggesting would be the right technique. Actually, ideally you > could do this: > > SecFilterSelective THE_REQUEST "vulnerable-script-name" chain > SecFilterSelective ARG_SANITIZEME s/</</ > SecFilterSelective ARG_SANITIZEME s/>/>/ > > But that too wouldn't work in mod_security I believe. Is this something > that could be added in future versions? Or maybe even a new directive > specifically for html escaping input? Something like: > > SecFilterSelective THE_REQUEST "vulnerable-script-name" chain > SecFilterHTMLEscape ARG_SANITIZEME > > I think it would be extremely useful to be able to modify request > content in this way rather than just flagging it. > > Tom > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > |
|
From: Ivan R. <iv...@we...> - 2006-01-13 12:59:31
|
Tom Anderson wrote: > > ... > > I'm not sure if you can use mod_security > to do this, but maybe you can try something like: > > SecFilterSelective THE_REQUEST "vulnerable-script-name" chain > SecFilterSelective ARG_SANITIZEME "(<|>)" "exec:html_escape.pl" > > But I don't think the exec'd script gets passed the info or inserts > anything back into the string. Ideally "html_escape.pl" would be passed > the "ARG_SANITIZEME" content on STDIN and then mod_security would > replace "ARG_SANITIZEME" with the output of "html_escape.pl". That > would be a true external filter, similar to how procmail works. Ivan, > correct me if I'm wrong in saying that you can't do using mod_security > what I'm suggesting would be the right technique. Actually, ideally you > could do this: > > SecFilterSelective THE_REQUEST "vulnerable-script-name" chain > SecFilterSelective ARG_SANITIZEME s/</</ > SecFilterSelective ARG_SANITIZEME s/>/>/ > > But that too wouldn't work in mod_security I believe. That's correct. It is not possible to change request data using ModSecurity, at least not at the moment. > Is this something > that could be added in future versions? I have been thinking about that but there's a lot of work involved and I just don't see the benefit. Personally, I don't believe in sanitisation. It's too easy to do it wrong, and if you do you get to feel secure where, in fact, you still have a hole in your defences. I am open to discussion, though. > I think it would be extremely useful to be able to modify request > content in this way rather than just flagging it. Perhaps, give me one real-life example where you would use it? -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com Tel: +44 20 8141 2161, Fax: +44 87 0762 3934 |
|
From: Tom A. <tan...@oa...> - 2006-01-13 15:00:34
|
Ivan Ristic wrote: >>I think it would be extremely useful to be able to modify request >>content in this way rather than just flagging it. > > > Perhaps, give me one real-life example where you would use it? > The present example of trying to prevent HTML injection in posts where user input is going to be displayed on a webpage, possibly by software that doesn't do proper sanitizing of its own. Doing little-constrained wildcard matching like "<.+?>" is a recipe for potentially huge performance hits, plus it wholesale rejects user input that should otherwise be acceptable in an escaped format. This would be true for SQL injection filters as well, and anywhere else that strings are blocked simply for containing dubious characters when they would be known OK if those characters could be escaped. Sanitizing functionality is like a bouncer at a club who checks IDs and stamps people's hands if they're over 21 so that they can order alcohol, and not reject from the club entirely those under 21. Likewise, you might not want to prevent people from having discussions _about_ HTML or SQL or other topics which might just contain strings that would trigger a filter block. Allow them to post their comments, but remove the attack potential by escaping those characters which would allow the strings to do damage under the wrong circumstances. Formats such as these might be ideal: SecFilterSelective ARG_BLOGPOST s/>/>/ SecFilterExternal ARG_BLOGPOST "html_escape.pl" SecFilterEscapeHTML ARG_BLOGPOST SecFilterEscapeSQL ARG_SEARCHSTRING Doing something like the last two should not be all that difficult, as simple generic escape functions can be written and simply applied to the argument listed. Just implementing SecFilterEscapeHTML ARG_BLOGPOST to replace SecFilterSelective ARG_BLOGPOST "<.+>" would both prevent lots of false positives (valid HTML discussions, etc) and measurably improve performance on moderately busy discussion forum or blog sites. This is real security, not just a perception... replacing key symbols with their HTML escape codes can annihilate HTML injection, XSS, and scripting attacks with little overhead. Tom |
|
From: Ivan R. <iv...@we...> - 2006-01-17 11:31:06
|
Tom Anderson wrote:
> Ivan Ristic wrote:
>>> I think it would be extremely useful to be able to modify request
>>> content in this way rather than just flagging it.
>>
>>
>> Perhaps, give me one real-life example where you would use it?
>>
> The present example of trying to prevent HTML injection in posts where
> user input is going to be displayed on a webpage, possibly by software
> that doesn't do proper sanitizing of its own. Doing little-constrained
> wildcard matching like "<.+?>" is a recipe for potentially huge
> performance hits, plus it wholesale rejects user input that should
> otherwise be acceptable in an escaped format.
There are two problems with data sanitisation if it is going
to be performed on a web application firewall level:
1. Transforming data from one format to another is not an operation
that should be performed in this layer. Ideally, the application
should be in possession of raw data and only transform it when
the data needs to cross a system boundary. For example, move
from the application into the database. If you choose to transform
data sitting on the outside you can perform only one transformation,
which only works when there is one system boundary.
2. In a general case, the only way to really know how the data
should be sanitised is to completely understand the application.
You'd have to know where the data is flowing and how many
system boundaries it is crossing. The current state of software
development is that we are having hard time getting the average
programmer to understand what they are doing ;) Web application
firewalls are managed by system administrators and security
people - I don't think it is realistic to expect them to
be able to understand applications on a sufficient level.
> Doing something like the last two should not be all that difficult, as
> simple generic escape functions can be written and simply applied to the
> argument listed. Just implementing SecFilterEscapeHTML ARG_BLOGPOST to
> replace SecFilterSelective ARG_BLOGPOST "<.+>" would both prevent lots
> of false positives (valid HTML discussions, etc) and measurably improve
> performance on moderately busy discussion forum or blog sites. This is
> real security, not just a perception... replacing key symbols with their
> HTML escape codes can annihilate HTML injection, XSS, and scripting
> attacks with little overhead.
Not in a general case. Depending on the application the "<" and ">"
characters may not be necessary to perform an XSS attack. This happens
for example, if the entry point for the intrusion is inside a tag
already, or inside JavaScript code.
--
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
Tel: +44 20 8141 2161, Fax: +44 87 0762 3934
|
|
From: Achim H. <ki...@se...> - 2006-01-13 21:23:35
|
On Fri, 13 Jan 2006, Ivan Ristic wrote:
!! Tom Anderson wrote:
!! >
!! > ...
!! >
!! > Is this something
!! > that could be added in future versions?
!!
!! I have been thinking about that but there's a lot of work involved
!! and I just don't see the benefit. Personally, I don't believe
!! in sanitisation. It's too easy to do it wrong, and if you do you
!! get to feel secure where, in fact, you still have a hole in your
!! defences.
!!
!! I am open to discussion, though.
I totally agree with Ivan: don't try to sanitize data at such a central place
!! > I think it would be extremely useful to be able to modify request
!! > content in this way rather than just flagging it.
!!
!! Perhaps, give me one real-life example where you would use it?
!!
OK, here we go, why you should not use something like s/</</
assume you have an URL with following QUERY_STRING:
cmd=ls
where someone uses (for fun or whatever:)
cmd=ls<i>/sbin/shutdown
which might be "sanitized" to:
cmd=ls<i>/sbin/shutdown
Hopefully the web server's application performing this request is not
running as user root, do you know ... ?
{-: Achim
|
|
From: Tom A. <tan...@oa...> - 2006-01-13 21:35:07
|
Achim Hoffmann wrote: > I totally agree with Ivan: don't try to sanitize data at such a central place I would tend to agree that sanitizing input should be done in the applicaiton itself. However, the main advantage of mod_security is that it is a central place to define security rules, and it runs before anything gets to the application layer which may be written by third parties and contain holes. In programs that I write, I do proper sanitizing before using any data, but if I'm using a standard package, I try to intercept problems before they get there. There's no reason that mod_security shouldn't have this functionality, especially since it's needed and useful in some circumstances, but users should understand that it's not necessarily the best place to do it. > OK, here we go, why you should not use something like s/</</ > > assume you have an URL with following QUERY_STRING: > cmd=ls > where someone uses (for fun or whatever:) > cmd=ls<i>/sbin/shutdown > which might be "sanitized" to: > cmd=ls<i>/sbin/shutdown Well, I wouldn't run that on the QUERY_STRING, I'd run it on a particular argument which is going to be posted as HTML to a webpage and not used in other contexts. Also, if you're allowing users to enter commands directly on the QUERY_STRING, you've got bigger problems! Tom |
|
From: Achim H. <ki...@se...> - 2006-01-14 20:26:44
|
On Fri, 13 Jan 2006, Tom Anderson wrote:
!! mod_security shouldn't have this functionality, especially since it's
!! needed and useful in some circumstances, but users should understand
!! that it's not necessarily the best place to do it.
that's the point.
IMHO you give users and programmers a wrong feeling of security if they
read somewhere that for example "mod_security can do input sanitation".
But that's another discussion, let Ivan deside how to go from here ..
!! > OK, here we go, why you should not use something like s/</</
!! >
!! > assume you have an URL with following QUERY_STRING:
!! > cmd=ls
!! > where someone uses (for fun or whatever:)
!! > cmd=ls<i>/sbin/shutdown
!! > which might be "sanitized" to:
!! > cmd=ls<i>/sbin/shutdown
!!
!! Well, I wouldn't run that on the QUERY_STRING, I'd run it on a
!! particular argument which is going to be posted as HTML to a webpage and
!! not used in other contexts. Also, if you're allowing users to enter
!! commands directly on the QUERY_STRING, you've got bigger problems!
This example is not restricted to GET, could be POST too, and it could
be expanded to be a combination of more than one parameter, and, and, and ...
My intention was just to show in a short example what's wrong with such
sanitations. Could have used a SQL injection example too. It's an example,
nothing more, nothing less.
{-: Achim
|
|
From: Ivan R. <iv...@we...> - 2006-01-13 12:48:38
|
Ivan Ristic wrote: > Servedio, Allen (Matrix) wrote: >> Just getting ready to... I am working with Ivan on it now. > > We didn't get to run truss (Allen did not have root on > the box) but we narrowed it down pretty much to a problem > in the Apache 1.3.x regular expression library. For those who remember a similar thread from December (increased CPU consumption when mod_security is used), we asked Kwong Li to remove the one rule in his configuration that used subexpressions. He has just reported that he has not experienced high load problems since. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com Tel: +44 20 8141 2161, Fax: +44 87 0762 3934 |
Thanks for helping keep SourceForge clean.
X