mod-security-developers — Development discussion about mod_security

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Rainer J. <rai...@ki...>]

On 13.02.2013 19:21, Curtis Wood wrote:
> Hi Guys,
> 
> Yes, mpm-event is experimental - and now with everything coming to
> light, that may be the whole problem along with the apr not being thread
> safe it sounds like?

The event MPM itself should not be the problem. The APR libraries were
originally developed as a basis for Apache 2 and many of the Apache devs
are also APR devs.

But the threaded nature of the Apache processes when using the event or
worker MPMs means that all modules must be programmed thread-safe too.
Most of the popular ones are though.

> After talking it over some we may just go with the prefork.

If that is an option for you, chances are good the problem vanishes.

> On the actual system - sry about that :-P We are on Linux X86_64, CentOS
> 5.9 - On the extra modules, we have ssl,fcgi,passenger,bw_limited and qos

Ah, lots of 3rd party. You could try to update to latest versions of
those. I don't have an indication, that those have a problem though.

> On when it happens - it can be at any time, originally when this came to
> light on a single site VPS, you could randomly click links to trigger it
> after a few minutes - while, clicking the same link twice would not
> guarantee anything. On the main servers which get a lot more traffic, it
> can be anywhere from hours to days.

ACK.

Rainer

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Curtis W. <cw...@si...>]

Hi Guys,

Yes, mpm-event is experimental - and now with everything coming to
light, that may be the whole problem along with the apr not being thread
safe it sounds like?

After talking it over some we may just go with the prefork.

On the actual system - sry about that :-P We are on Linux X86_64, CentOS
5.9 - On the extra modules, we have ssl,fcgi,passenger,bw_limited and qos

On when it happens - it can be at any time, originally when this came to
light on a single site VPS, you could randomly click links to trigger it
after a few minutes - while, clicking the same link twice would not
guarantee anything. On the main servers which get a lot more traffic, it
can be anywhere from hours to days.


On 02/13/2013 11:17 AM, Rainer Jung wrote:
> On 13.02.2013 16:51, Breno Silva wrote:
>> Curtis,
>>
>> Yes. APR pools are not thread safe. I think mpm-event is an experimental
>> code in Apache 2.2 right ? I think it is stable in Apache 2.4.
>> Any chance you try to setup one box with Apache 2.4 and see what happens ?
>>
>> Also what platform are you using ? x86, x86_64 ? Are you using Linux ?
>> Glib has support to Epoll ?
> Adding to the question list:
>
> - do you have any other third party modules loaded, i.e. apart from the
> ones that come bundled with Apache or mod_security?
>
> - does it only happen during or after periods of high load/concurrency ?
>
> Regards,
>
> Rainer
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Rainer J. <rai...@ki...>]

On 13.02.2013 16:51, Breno Silva wrote:
> Curtis,
> 
> Yes. APR pools are not thread safe. I think mpm-event is an experimental
> code in Apache 2.2 right ? I think it is stable in Apache 2.4.
> Any chance you try to setup one box with Apache 2.4 and see what happens ?
> 
> Also what platform are you using ? x86, x86_64 ? Are you using Linux ?
> Glib has support to Epoll ?

Adding to the question list:

- do you have any other third party modules loaded, i.e. apart from the
ones that come bundled with Apache or mod_security?

- does it only happen during or after periods of high load/concurrency ?

Regards,

Rainer

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Breno S. <bre...@gm...>]

Curtis,

Yes. APR pools are not thread safe. I think mpm-event is an experimental
code in Apache 2.2 right ? I think it is stable in Apache 2.4.
Any chance you try to setup one box with Apache 2.4 and see what happens ?

Also what platform are you using ? x86, x86_64 ? Are you using Linux ? Glib
has support to Epoll ?

Thanks

Breno

On Wed, Feb 13, 2013 at 12:53 PM, Curtis Wood <cw...@si...> wrote:

>  Hi Breno,
>
> We are using the following rules - with the exception of excluding some
> particular rule ID's or white listing IP's here and there, there isn't
> anything really custom.
>
> /var/asl/rules/10_asl_rules.conf
> /var/asl/rules/20_asl_useragents.conf
> /var/asl/rules/30_asl_antispam.conf
> /var/asl/rules/50_asl_rootkits.conf
> /var/asl/rules/60_asl_recons.conf
> /var/asl/rules/99_asl_jitp.conf
>
> We are using the mpm_event - as opposed to the mpm_prefork which I
> understand is what is not threaded, could this be the underlying issue as
> Rainer mentioned?
>
> Following up with Rainers point, the APR pools are becoming corrupt - I
> dont recall the particular function (there are a few of them) with the
> following loop, all though the node in the linked list is basically
> pointing to it self so, never gets freed up and consequently the loop goes
> on for ever - the 'fix' we implemented originally in libapr was to simply
> add a conditional break statement based on whether "c == c->next"..
>
> (in run_child_cleanups())
>
>     while (c) {
>         *cref = c->next;
>         (*c->child_cleanup_fn)((void *)c->data);
>         c = *cref;
>
>     }
>
>
> On 02/13/2013 05:55 AM, Breno Silva wrote:
>
> Curtis,
>
> Are you using some custom ruleset ? or using only CRS ?
> Maybe i can copy your configuration/ruleset and try to reproduce, for
> better investigation
>
> Thanks
>
> Breno
>
>  On Wed, Feb 13, 2013 at 12:05 AM, Rainer Jung <rai...@ki...>wrote:
>
>> On 12.02.2013 22:26, Curtis Wood wrote:
>> > Hi All,
>> >
>> > We seem to have found a potential issue with mod security - we are using
>> > cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a strange
>> > issue with Apache last year where it would be getting caught in an
>> > internal loop with the apr_pool_cleanup routines - essentially trying to
>> > clear the same pool over and over. Initially it was thought to only be
>> > with this customers particular website/setup - although recently we saw
>> > the same issues on our production servers and have verified it is same
>> > issue.
>> >
>> > We have disabled modsec2 fleet wide (2500+ servers) and the problem has
>> > ceased to exist at this time. Unfortunately we have no idea what
>> > triggers this, if it's a particular URL being accessed or what.
>>
>>  Pool cleanup loops typically indicate a corruption in the pool data
>> structures due to unsynchronized pool use by multiple threads. APR pools
>> are not thread-safe.
>>
>> Regards,
>>
>> Rainer
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> _______________________________________________
>> mod-security-developers mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.http://p.sf.net/sfu/sophos-d2d-feb
>
>
>
> _______________________________________________
> mod-security-developers mailing lis...@li...://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:https://www.trustwave.com/spiderLabs.php
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Curtis W. <cw...@si...>]

Hi Breno,

We are using the following rules - with the exception of excluding some
particular rule ID's or white listing IP's here and there, there isn't
anything really custom.

/var/asl/rules/10_asl_rules.conf
/var/asl/rules/20_asl_useragents.conf
/var/asl/rules/30_asl_antispam.conf
/var/asl/rules/50_asl_rootkits.conf
/var/asl/rules/60_asl_recons.conf
/var/asl/rules/99_asl_jitp.conf

We are using the mpm_event - as opposed to the mpm_prefork which I
understand is what is not threaded, could this be the underlying issue
as Rainer mentioned?

Following up with Rainers point, the APR pools are becoming corrupt - I
dont recall the particular function (there are a few of them) with the
following loop, all though the node in the linked list is basically
pointing to it self so, never gets freed up and consequently the loop
goes on for ever - the 'fix' we implemented originally in libapr was to
simply add a conditional break statement based on whether "c == c->next"..

(in run_child_cleanups())

    while (c) {
        *cref = c->next;
        (*c->child_cleanup_fn)((void *)c->data);
        c = *cref;
    }


On 02/13/2013 05:55 AM, Breno Silva wrote:
> Curtis,
>
> Are you using some custom ruleset ? or using only CRS ?
> Maybe i can copy your configuration/ruleset and try to reproduce, for
> better investigation
>
> Thanks
>
> Breno
>
> On Wed, Feb 13, 2013 at 12:05 AM, Rainer Jung <rai...@ki...
> <mailto:rai...@ki...>> wrote:
>
>     On 12.02.2013 22:26, Curtis Wood wrote:
>     > Hi All,
>     >
>     > We seem to have found a potential issue with mod security - we
>     are using
>     > cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a
>     strange
>     > issue with Apache last year where it would be getting caught in an
>     > internal loop with the apr_pool_cleanup routines - essentially
>     trying to
>     > clear the same pool over and over. Initially it was thought to
>     only be
>     > with this customers particular website/setup - although recently
>     we saw
>     > the same issues on our production servers and have verified it
>     is same
>     > issue.
>     >
>     > We have disabled modsec2 fleet wide (2500+ servers) and the
>     problem has
>     > ceased to exist at this time. Unfortunately we have no idea what
>     > triggers this, if it's a particular URL being accessed or what.
>
>     Pool cleanup loops typically indicate a corruption in the pool data
>     structures due to unsynchronized pool use by multiple threads. APR
>     pools
>     are not thread-safe.
>
>     Regards,
>
>     Rainer
>
>
>     ------------------------------------------------------------------------------
>     Free Next-Gen Firewall Hardware Offer
>     Buy your Sophos next-gen firewall before the end March 2013
>     and get the hardware for free! Learn more.
>     http://p.sf.net/sfu/sophos-d2d-feb
>     _______________________________________________
>     mod-security-developers mailing list
>     mod...@li...
>     <mailto:mod...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>     ModSecurity Services from Trustwave's SpiderLabs:
>     https://www.trustwave.com/spiderLabs.php
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
>
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Breno S. <bre...@gm...>]

Curtis,

Are you using some custom ruleset ? or using only CRS ?
Maybe i can copy your configuration/ruleset and try to reproduce, for
better investigation

Thanks

Breno

On Wed, Feb 13, 2013 at 12:05 AM, Rainer Jung <rai...@ki...>wrote:

> On 12.02.2013 22:26, Curtis Wood wrote:
> > Hi All,
> >
> > We seem to have found a potential issue with mod security - we are using
> > cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a strange
> > issue with Apache last year where it would be getting caught in an
> > internal loop with the apr_pool_cleanup routines - essentially trying to
> > clear the same pool over and over. Initially it was thought to only be
> > with this customers particular website/setup - although recently we saw
> > the same issues on our production servers and have verified it is same
> > issue.
> >
> > We have disabled modsec2 fleet wide (2500+ servers) and the problem has
> > ceased to exist at this time. Unfortunately we have no idea what
> > triggers this, if it's a particular URL being accessed or what.
>
> Pool cleanup loops typically indicate a corruption in the pool data
> structures due to unsynchronized pool use by multiple threads. APR pools
> are not thread-safe.
>
> Regards,
>
> Rainer
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_nullloop in Apache

[Rainer J. <rai...@ki...>]

On 12.02.2013 22:26, Curtis Wood wrote:
> Hi All,
> 
> We seem to have found a potential issue with mod security - we are using
> cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a strange
> issue with Apache last year where it would be getting caught in an
> internal loop with the apr_pool_cleanup routines - essentially trying to
> clear the same pool over and over. Initially it was thought to only be
> with this customers particular website/setup - although recently we saw
> the same issues on our production servers and have verified it is same
> issue.
> 
> We have disabled modsec2 fleet wide (2500+ servers) and the problem has
> ceased to exist at this time. Unfortunately we have no idea what
> triggers this, if it's a particular URL being accessed or what.

Pool cleanup loops typically indicate a corruption in the pool data
structures due to unsynchronized pool use by multiple threads. APR pools
are not thread-safe.

Regards,

Rainer

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_null loop in Apache

[Curtis W. <cw...@si...>]

Hi Breno,

We have seen this with both apr 1.4.5 and 1.4.6..

libapr-1.so.0.4.6
libapr-1.so.0.4.5

I've submitted something to apache as well - asking if they have any
insight on this also.

Do you have any suggestions on how to possibly try and reproduce this?
I'm assuming (if its related to modsec) it's some particular URL that it
may be trying to parse - in which apache isnt going to log anything (to
get the URL) until it has finished processing everything?


On 02/12/2013 04:36 PM, Breno Silva wrote:
> Hello Curtis,
>
> What is your apr library version ? I suppose it could be apr bug. I
> would like to check in apr project and see if i can find something
> related to apr_pool_cleanup_null.
>
> Thanks
>
> Breno
>
> On Tue, Feb 12, 2013 at 7:26 PM, Curtis Wood <cw...@si...
> <mailto:cw...@si...>> wrote:
>
>     Hi All,
>
>     We seem to have found a potential issue with mod security - we are
>     using
>     cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a
>     strange
>     issue with Apache last year where it would be getting caught in an
>     internal loop with the apr_pool_cleanup routines - essentially
>     trying to
>     clear the same pool over and over. Initially it was thought to only be
>     with this customers particular website/setup - although recently
>     we saw
>     the same issues on our production servers and have verified it is same
>     issue.
>
>     We have disabled modsec2 fleet wide (2500+ servers) and the
>     problem has
>     ceased to exist at this time. Unfortunately we have no idea what
>     triggers this, if it's a particular URL being accessed or what.
>
>     Apache's 3rd level children consuming much of the CPU..
>
>     nobody   51805  1.1  2.2 837744 273500 ?       Sl   15:58   0:24
>      \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    2884 46.1  2.1 837744 263912 ?       R    16:29   1:24
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    3955 47.3  2.1 837744 264148 ?       R    16:30   1:02
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    3981 45.3  2.1 837744 264164 ?       R    16:30   0:58
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    3986 47.1  2.1 837744 264164 ?       R    16:30   1:00
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    4024 47.2  2.1 837744 264168 ?       R    16:30   0:58
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    4031 51.2  2.1 837744 264176 ?       R    16:30   1:02
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     nobody    4052 46.6  2.1 837744 264176 ?       R    16:30   0:55
>      |   \_ /usr/local/apache/bin/httpd -k start -DSSL
>     ...
>     ...
>
>     2nd indication is an ltrace on the effected process, the
>     apr_pool_cleanup_null is caught in a loop..
>
>     apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     apr_pool_cleanup_null(0x2914f10, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     apr_pool_cleanup_null(0x2914ed8, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     apr_pool_cleanup_null(0x2914f10, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     apr_pool_cleanup_null(0x2914ed8, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)  
>                                                                    = 0
>     ...
>     ...
>
>     If you try and strace the process, it just sits there as there are
>     no system calls being made - its just caught in a loop of sorts.
>
>     On the main production servers, the load can escalate to 30-40
>     normally from this - and refusing to take any new connections,
>     while on a smaller VPS the load can sky rocket to 300 in a matter
>     of seconds and taking it down.
>
>     Has anyone else seen anything like this, and have any pointers as
>     to how to hunt down what is really causing it or to even reproduce
>     it? Unfortunately since we have disabled modsec - security issues
>     are on the rise again, and obviously we would like to have this
>     re-implemented.
>
>
>     --
>     Curtis Wood
>
>
>     ------------------------------------------------------------------------------
>     Free Next-Gen Firewall Hardware Offer
>     Buy your Sophos next-gen firewall before the end March 2013
>     and get the hardware for free! Learn more.
>     http://p.sf.net/sfu/sophos-d2d-feb
>     _______________________________________________
>     mod-security-developers mailing list
>     mod...@li...
>     <mailto:mod...@li...>
>     https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>     ModSecurity Services from Trustwave's SpiderLabs:
>     https://www.trustwave.com/spiderLabs.php
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
>
>
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] ModSec triggering apr_pool_cleanup_null loop in Apache

[Breno S. <bre...@gm...>]

Hello Curtis,

What is your apr library version ? I suppose it could be apr bug. I would
like to check in apr project and see if i can find something related to
apr_pool_cleanup_null.

Thanks

Breno

On Tue, Feb 12, 2013 at 7:26 PM, Curtis Wood <cw...@si...> wrote:

> Hi All,
>
> We seem to have found a potential issue with mod security - we are using
> cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a strange
> issue with Apache last year where it would be getting caught in an
> internal loop with the apr_pool_cleanup routines - essentially trying to
> clear the same pool over and over. Initially it was thought to only be
> with this customers particular website/setup - although recently we saw
> the same issues on our production servers and have verified it is same
> issue.
>
> We have disabled modsec2 fleet wide (2500+ servers) and the problem has
> ceased to exist at this time. Unfortunately we have no idea what
> triggers this, if it's a particular URL being accessed or what.
>
> Apache's 3rd level children consuming much of the CPU..
>
> nobody   51805  1.1  2.2 837744 273500 ?       Sl   15:58   0:24  \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    2884 46.1  2.1 837744 263912 ?       R    16:29   1:24  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    3955 47.3  2.1 837744 264148 ?       R    16:30   1:02  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    3981 45.3  2.1 837744 264164 ?       R    16:30   0:58  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    3986 47.1  2.1 837744 264164 ?       R    16:30   1:00  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    4024 47.2  2.1 837744 264168 ?       R    16:30   0:58  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    4031 51.2  2.1 837744 264176 ?       R    16:30   1:02  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> nobody    4052 46.6  2.1 837744 264176 ?       R    16:30   0:55  |   \_
> /usr/local/apache/bin/httpd -k start -DSSL
> ...
> ...
>
> 2nd indication is an ltrace on the effected process, the
> apr_pool_cleanup_null is caught in a loop..
>
> apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> apr_pool_cleanup_null(0x2914f10, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> apr_pool_cleanup_null(0x2914ed8, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> apr_pool_cleanup_null(0x2914f10, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> apr_pool_cleanup_null(0x2914ed8, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)
>                                                        = 0
> ...
> ...
>
> If you try and strace the process, it just sits there as there are no
> system calls being made - its just caught in a loop of sorts.
>
> On the main production servers, the load can escalate to 30-40 normally
> from this - and refusing to take any new connections, while on a smaller
> VPS the load can sky rocket to 300 in a matter of seconds and taking it
> down.
>
> Has anyone else seen anything like this, and have any pointers as to how
> to hunt down what is really causing it or to even reproduce it?
> Unfortunately since we have disabled modsec - security issues are on the
> rise again, and obviously we would like to have this re-implemented.
>
>
> --
> Curtis Wood
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
>

[Mod-security-developers] ModSec triggering apr_pool_cleanup_null loop in Apache

[Curtis W. <cw...@si...>]

Hi All,

We seem to have found a potential issue with mod security - we are using
cPanel along with Apache 2.2.23/mod_security 2.7.1. We noticed a strange
issue with Apache last year where it would be getting caught in an
internal loop with the apr_pool_cleanup routines - essentially trying to
clear the same pool over and over. Initially it was thought to only be
with this customers particular website/setup - although recently we saw
the same issues on our production servers and have verified it is same
issue.

We have disabled modsec2 fleet wide (2500+ servers) and the problem has
ceased to exist at this time. Unfortunately we have no idea what
triggers this, if it's a particular URL being accessed or what.

Apache's 3rd level children consuming much of the CPU..

nobody   51805  1.1  2.2 837744 273500 ?       Sl   15:58   0:24  \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    2884 46.1  2.1 837744 263912 ?       R    16:29   1:24  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    3955 47.3  2.1 837744 264148 ?       R    16:30   1:02  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    3981 45.3  2.1 837744 264164 ?       R    16:30   0:58  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    3986 47.1  2.1 837744 264164 ?       R    16:30   1:00  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    4024 47.2  2.1 837744 264168 ?       R    16:30   0:58  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    4031 51.2  2.1 837744 264176 ?       R    16:30   1:02  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
nobody    4052 46.6  2.1 837744 264176 ?       R    16:30   0:55  |   \_ /usr/local/apache/bin/httpd -k start -DSSL
...
...

2nd indication is an ltrace on the effected process, the apr_pool_cleanup_null is caught in a loop..

apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
apr_pool_cleanup_null(0x2914f10, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
apr_pool_cleanup_null(0x2914ed8, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
apr_pool_cleanup_null(0x2914f10, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
apr_pool_cleanup_null(0x2914ed8, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
apr_pool_cleanup_null(0x2914ea0, 2, 0x42a9f0, 0, 0x7a62efdaa940)                                                                  = 0
...
...

If you try and strace the process, it just sits there as there are no system calls being made - its just caught in a loop of sorts.

On the main production servers, the load can escalate to 30-40 normally from this - and refusing to take any new connections, while on a smaller VPS the load can sky rocket to 300 in a matter of seconds and taking it down.

Has anyone else seen anything like this, and have any pointers as to how to hunt down what is really causing it or to even reproduce it? Unfortunately since we have disabled modsec - security issues are on the rise again, and obviously we would like to have this re-implemented.


-- 
Curtis Wood

[Mod-security-developers] [JIRA] Resolved: (MODSEC-366) Modsecurity with Nginx 1.3.9 fail to build due to changes in Nginx

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-366.
--------------------------------------

    Fix Version/s: 2.7.3
       Resolution: Fixed

> Modsecurity with Nginx 1.3.9 fail to build due to changes in Nginx
> ------------------------------------------------------------------
>
>                 Key: MODSEC-366
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-366
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Build System
>    Affects Versions: 2.7.1
>         Environment: Centos 5.8, Nginx 1.3.9
>            Reporter: Aditya W
>            Assignee: Breno Silva Pinto
>              Labels: nginx
>             Fix For: 2.7.3
>
>
> Compiling Modsecurity 2.7.1 with Nginx 1.3.9 will result in build failure due to change in Nginx
>                 ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c: In function 'ngx_http_read_upload_client_request_body':
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c:369: error: 'ngx_http_request_body_t' has no member named 'to_write'
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c:426: error: 'ngx_http_request_body_t' has no member named 'to_write'
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c: In function 'ngx_http_do_read_upload_client_request_body':
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c:490: error: 'ngx_http_request_body_t' has no member named 'to_write'
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c:495: error: 'ngx_http_request_body_t' has no member named 'to_write'
> ../modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c:561: error: 'ngx_http_request_body_t' has no member named 'to_write'
> make[1]: *** [objs/addon/modsecurity/ngx_http_modsecurity.o] Error 1
> Another nginx module that is broke due to change in Nginx 1.3.9 is https://github.com/vkholodkov/nginx-upload-module/issues/41

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-377) Errors on compiling with Nginx

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-377.
--------------------------------------

    Resolution: Won't Fix

> Errors on compiling with Nginx
> ------------------------------
>
>                 Key: MODSEC-377
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-377
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>    Affects Versions: 2.7.1
>         Environment: uname -a
> Linux tamas 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> lsb_release -a
> Distributor ID: Ubuntu
> Description: Ubuntu 12.04.1 LTS
> Release: 12.04
> Codename: precise
> gcc version: 4.6.3
> nginx version: 1.2.6
>            Reporter: Tamas Kokeny
>            Assignee: Breno Silva Pinto
>              Labels: nginx
>             Fix For: 2.7.3
>
>
> I get errors, when I try to compile Nginx with ModSecurity and ngx_http_extended_status_module.
> In file included from /usr/include/apache2/mod_log_config.h:28:0,
>                  from /home/nginx/modsecurity-apache_2.7.1/nginx/modsecurity/../../standalone/api.h:29,
>                  from /home/nginx/modsecurity-apache_2.7.1/nginx/modsecurity/ngx_http_modsecurity.c:28:
> /usr/include/apache2/scoreboard.h:58:0: error: "SERVER_DEAD" redefined [-Werror]
> src/event/ngx_event.h:532:0: note: this is the location of the previous definition
> /usr/include/apache2/scoreboard.h:60:0: error: "SERVER_READY" redefined [-Werror]
> src/event/ngx_event.h:528:0: note: this is the location of the previous definition
> /usr/include/apache2/scoreboard.h:61:0: error: "SERVER_BUSY_READ" redefined [-Werror]
> src/event/ngx_event.h:529:0: note: this is the location of the previous definition
> /usr/include/apache2/scoreboard.h:62:0: error: "SERVER_BUSY_WRITE" redefined [-Werror]
> src/event/ngx_event.h:530:0: note: this is the location of the previous definition
> /usr/include/apache2/scoreboard.h:64:0: error: "SERVER_BUSY_LOG" redefined [-Werror]
> src/event/ngx_event.h:531:0: note: this is the location of the previous definition
> /usr/include/apache2/scoreboard.h:100:29: error: conflicting types for 'worker_score'
> src/event/ngx_event.h:551:3: note: previous declaration of 'worker_score' was here
> cc1: all warnings being treated as errors
> make[1]: *** [objs/addon/modsecurity/ngx_http_modsecurity.o] Error 1
> make[1]: Leaving directory `/home/nginx/nginx-1.2.6'
> make: *** [build] Error 2

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-376) Nginx server returns 500 instead of 403

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-376.
--------------------------------------

    Resolution: Fixed

> Nginx server returns 500 instead of 403
> ---------------------------------------
>
>                 Key: MODSEC-376
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-376
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>    Affects Versions: 2.7.1
>         Environment: uname -a
> Linux tamas 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
> lsb_release -a
> Distributor ID:	Ubuntu
> Description:	Ubuntu 12.04.1 LTS
> Release:	12.04
> Codename:	precise
> nginx -V
> nginx version: nginx/1.2.6
> built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --with-http_ssl_module --with-debug --sbin-path=/sbin/nginx --conf-path=/etc/nginx/nginx.conf --with-http_stub_status_module --add-module=/home/modsecurity-apache_2.7.1/nginx/modsecurity
>            Reporter: Tamas Kokeny
>            Assignee: Breno Silva Pinto
>              Labels: nginx
>             Fix For: 2.7.3
>
>
> When I try to use my customised rule (SecRule TIME_HOUR "(19|20)" phase:2,auditlog,id:1,deny,log), Nginx returns 500 instead of ModSecurity's 403.
> nginx.debug.log:
> 2013/01/10 20:48:26 [debug] 20797#0: *1 modSecurity: handler
> 2013/01/10 20:48:26 [debug] 20797#0: *1 modSecurity: method is not POST
> 2013/01/10 20:48:26 [debug] 20797#0: *1 modSecurity: pass_to_backend
> 2013/01/10 20:48:26 [debug] 20797#0: *1 ModSecurity: status: 403, need action
> 2013/01/10 20:48:26 [debug] 20797#0: *1 http finalize request: 500, "/pic2.png?" a:1, c:1
> 2013/01/10 20:48:26 [debug] 20797#0: *1 http special response: 500, "/pic2.png?"
> 2013/01/10 20:48:26 [debug] 20797#0: *1 http set discard body
> 2013/01/10 20:48:26 [debug] 20797#0: *1 HTTP/1.1 500 Internal Server Error
> modsecurity.error.log:
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Initialising transaction (txid 12345).
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Transaction context created (dcfg 7fd8abe00980).
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Starting phase REQUEST_HEADERS.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][9] This phase consists of 0 rule(s).
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Second phase starting (dcfg 7fd8abe00980).
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Input filter: This request does not have a body.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Starting phase REQUEST_BODY.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][9] This phase consists of 1 rule(s).
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Recipe: Invoking rule 7fd8abde9700; [file "/etc/nginx/modsecurity.conf"] [line "5"] [id "1"].
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][5] Rule 7fd8abde9700: SecRule "TIME_HOUR" "@rx (19|20)" "phase:2,auditlog,id:1,deny,log"
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Transformation completed in 4 usec.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Executing operator "rx" with param "(19|20)" against TIME_HOUR.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][9] Target value: "20"
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][6] Ignoring regex captures since "capture" action is not enabled.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Operator completed in 44 usec.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Rule returned 1.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][9] Match, intercepted -> returning.
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][1] Access denied with code 403 (phase 2). Pattern match "(19|20)" at TIME_HOUR. [file "/etc/nginx/modsecurity.conf"] [line "5"] [id "1"]
> [10/Jan/2013:20:48:26 +0100] [standalone/sid#7fd8abdfe0a0][rid#7fd8abdb30a0][/pic2.png][4] Hook insert_filter: Adding output filter (r 7fd8abdb30a0).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Re: [Mod-security-developers] Nginx port

[Aaron B. <aar...@gm...>]

I have one. Contact me off list and we can work something out.

-Aaron

Sent from my iPhone

On Jan 29, 2013, at 7:37 AM, Breno Silva <bre...@gm...> wrote:

> Hello list,
> 
> I'm working on the nginx port issue and i need a high traffic environment to test a situation.
> Let me know if any of you have this environment to test ?
> 
> Thanks
> 
> Breno
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php

[Mod-security-developers] Nginx port

[Breno S. <bre...@gm...>]

Hello list,

I'm working on the nginx port issue and i need a high traffic environment
to test a situation.
Let me know if any of you have this environment to test ?

Thanks

Breno

[Mod-security-developers] [JIRA] Resolved: (MODSEC-365) Segfault in Nginx with Modsecurity if user didn't put the modsecurity directives

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-365.
--------------------------------------

    Resolution: Fixed

Hello Aditya,

I tested with the latest trunk and looks fixed. If you can test and give me a feedback would be good.

Thanks

Breno

> Segfault in Nginx with Modsecurity if user didn't put the modsecurity directives
> --------------------------------------------------------------------------------
>
>                 Key: MODSEC-365
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-365
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Core
>    Affects Versions: 2.7.1
>         Environment: Centos 5.8 x86, Nginx 1.3.8
>            Reporter: Aditya W
>            Assignee: Breno Silva Pinto
>            Priority: Low
>              Labels: nginx, segfault
>             Fix For: 2.7.3
>
>
> If a user compiled modsecurity with nginx and the user didn't write both ..
> ModSecurityEnabled on/off
> ModSecurityConfig xxxxx
> in the appropriate section of his/her configuration file, when the user started nginx it'll be segfault
> 2012/12/05 09:25:29 [alert] 28916#0: cache manager process 32671 exited on signal 11
> 2012/12/05 09:25:29 [alert] 28916#0: worker process 32672 exited on signal 11
> 2012/12/05 09:25:29 [alert] 28916#0: worker process 32673 exited on signal 11
> 2012/12/05 09:25:29 [alert] 28916#0: worker process 32674 exited on signal 11
> 2012/12/05 09:25:29 [alert] 28916#0: worker process 32675 exited on signal 11
> and it keeps on looping and filling the log file

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-374) Nginx worker process segfault when using SecAuditEngine

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-374.
--------------------------------------

    Resolution: Fixed

Hello Andreas,

I tested the new trunk and it looks like fixed. I'm just seeing a Permission denied msg that must be fixed. However no more seg faults.

let me know if you can test and give me a feddback.

Thanks

Breno

> Nginx worker process segfault when using SecAuditEngine
> -------------------------------------------------------
>
>                 Key: MODSEC-374
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-374
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Logging
>         Environment: Debian Linux 6, Nginx 1.3.8, mod_security from trunk (07.01.2013)
>            Reporter: Andreas Jaggi
>            Assignee: Breno Silva Pinto
>              Labels: nginx
>             Fix For: 2.7.3
>
>
> When having SecAuditEngine set to On or RelevantOnly, everytime a ModSec rule (I'm using OWASP CRS rules) matches, the nginx worker segfaults and does not write to SecAuditLog (I have SecAuditLogType set to Serial), the request is properly handled though and the ModSec debuglog shows the matched CRS rule.
> Logfiles:
> ==> /var/log/nginx/error.log <==
> 2013/01/08 14:24:33 [info] 7558#0: [client 213.156.230.133] ModSecurity: Warning. Pattern match "(?i:(?:union\\s*?(?:all|distinct|[(!@]*?)?\\s*?[([]*?\\s*?select)|(?:\\w+\\s+like\\s+[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98])|(?:like\\s*?[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\%)|(?:[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\s*?like\\W*?[\"'`\xc2\xb4\xe2 ..." at ARGS:foo. [file "/etc/nginx/mod_security.rpx.real.jaggi.info.conf.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "223"] [id "981245"] [msg "Detects basic SQL authentication bypass attempts 2/3"] [data "Matched Data: select from found within ARGS:foo: select from"] [severity "CRITICAL"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [hostname "standalone"] [uri "/ip/?foo=select%20from"] [unique_id "12345"]
> ==> /var/log/nginx/rpx.real.jaggi.info-ip.access.log <==
> 213.156.230.133 - - [08/Jan/2013:14:24:33 +0100]  "GET /ip/?foo=select%20from HTTP/1.1" 200 27 "-" "curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5" 0.038
> ==> /var/log/nginx/error.log <==
> 2013/01/08 14:24:33 [alert] 7554#0: worker process 7558 exited on signal 11
> ModSec Debug Log:
> [08/Jan/2013:14:24:33 +0100] [standalone/sid#19d3470][rid#22e8db0][/ip/?foo=select%20from][2] Warning. Pattern match "(?i:(?:union\\s*?(?:all|distinct|[(!@]*?)?\\s*?[([]*?\\s*?select)|(?:\\w+\\s+like\\s+[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98])|(?:like\\s*?[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\%)|(?:[\"'`\xc2\xb4\xe2\x80\x99\xe2\x80\x98]\\s*?like\\W*?[\"'`\xc2\xb4\xe2 ..." at ARGS:foo. [file "/etc/nginx/mod_security.rpx.real.jaggi.info.conf.d/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"] [line "223"] [id "981245"] [msg "Detects basic SQL authentication bypass attempts 2/3"] [data "Matched Data: select from found within ARGS:foo: select from"] [severity "CRITICAL"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-348) initcol not working with NGINX port of mod_sec

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-348.
--------------------------------------

    Resolution: Fixed

Hello Mike,

I did some tests with the new trunk. Looks fixed.
If you can test and send a feedback.

Thanks

Breno

> initcol not working with NGINX port of mod_sec
> ----------------------------------------------
>
>                 Key: MODSEC-348
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-348
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Actions, Core, Logging
>    Affects Versions: 2.7.0
>         Environment: EL6
>            Reporter: Mike Fisher
>            Assignee: Breno Silva Pinto
>             Fix For: 2.7.3
>
>
> I've already reported this by mail 14 days ago, but want to make sure it doesn't get lost, so I'm creating this bug report.
> With the current NGINX version of mod_security, if you use rules that include initcol, such as "initcol:ip=%{REMOTE_ADDR}", the collection file doesn't get written at all (eg. '/tmp/ip' or '/tmp/ip.pag' in my example case). Therefore it's impossible to track IPs/actions and so on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] Availability of ModSecurity 2.7.2 Stable Release

[Breno S. <bre...@gm...>]

The ModSecurity Development Team is pleased to announce the availability of
ModSecurity 2.7.2 Stable Release.
The stability of this release is good and includes many bug fixes.

We have fixed some build system issues and also set IIS version as stable.
We also included some fixes for NGINX version and remove the
ModSecurityPass command.
Some fixes were included, specially into cpf_verify and ipmatchf operators.
Please see the release notes included into CHANGES file.

For known problems and more information about bug fixes, please see the
online ModSecurity Jira. Please report any bug to
mod...@li....

Thanks

Breno Silva

[Mod-security-developers] Integration of libinjection

[Ryan B. <RBa...@tr...>]

Please refer to the following presentation - http://www.slideshare.net/nickgsuperstar/libinjection-isecpartners.  GitHub Report here - https://github.com/client9/libinjection.  The idea is to add in a new operator called something like "@detectSQLi".  You would pass to it the name of the fingerprints.txt file.  So it would be used like this -

SecRule ARGS "@detectSQLi /path/to/fingerprints.txt"

I think this would be a great addition.  If anyone is interested in helping to add libinjection support to ModSecurity please let me know.

--
Ryan Barnett
Trustwave SpiderLabs
ModSecurity Project Leader
OWASP ModSecurity CRS Project Leader

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

[Mod-security-developers] [JIRA] Resolved: (MODSEC-371) ModsecurityIIS does not pass through POST data to ASP.NET when SecRequestBodyAccess is set to On

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-371.
--------------------------------------

    Fix Version/s: 2.7.2
       Resolution: Fixed

> ModsecurityIIS does not pass through POST data to ASP.NET when SecRequestBodyAccess is set to On
> ------------------------------------------------------------------------------------------------
>
>                 Key: MODSEC-371
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-371
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>    Affects Versions: 2.7.1
>         Environment: Windows 2008 R2/IIS 7.5
>            Reporter: Magnus Eriksson
>            Assignee: Breno Silva Pinto
>            Priority: High
>              Labels: IIS, ModSecurityIIS
>             Fix For: 2.7.2
>
>
> ModsecurityIIS does not pass through POST data to ASP.NET when SecRequestBodyAccess is set to On. Configuration file was based on modsecurity.conf-recommended.
> This was confirmed by creating a simple page with a single textbox and button. When turning SecRequestBodyAccess to Off and submitting the form, we get 4 items in HttpContext.Current.Request.Form.AllKeys. When SecRequestBodyAccess is set to On I get 0 items in HttpContext.Current.Request.Form.AllKeys.
> There is nothing in the logs to indicate anything has been blocked. There is also nothing in the event log.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-372) OWASP ModSecurity Core Rule Set used with ModsecurityIIS causes AppPool death

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-372.
--------------------------------------

    Fix Version/s: 2.7.2
       Resolution: Fixed

> OWASP ModSecurity Core Rule Set used with ModsecurityIIS causes AppPool death
> -----------------------------------------------------------------------------
>
>                 Key: MODSEC-372
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-372
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>    Affects Versions: 2.7.1
>         Environment: Windows 2008 R2/IIS 7.5
>            Reporter: Magnus Eriksson
>            Assignee: Breno Silva Pinto
>              Labels: IIS, ModSecurityIIS
>             Fix For: 2.7.2
>
>
> When using ModsecurityIIS with OWASP ModSecurity Core Rule Set, modsecurityiis.dll crashes with the following errors in the event log:
> Log Name:      Application
> Source:        Application Error
> Date:          2/01/2013 6:05:01 PM
> Event ID:      1000
> Task Category: (100)
> Level:         Error
> Keywords:      Classic
> User:          N/A
> Computer:      xxxxxxx
> Description:
> Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8
> Faulting module name: modsecurityiis.dll, version: 0.0.0.0, time stamp: 0x50a2b51d
> Exception code: 0xc0000005
> Fault offset: 0x0002ad30
> Faulting process id: 0x720
> Faulting application start time: 0x01cde8b7783dfea0
> Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
> Faulting module path: C:\Windows\system32\inetsrv\modsecurityiis.dll
> Report Id: b9749a71-54aa-11e2-abfd-0026554839ff
> This brings down the app pool. This has been confirmed on 2 separate servers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] [JIRA] Resolved: (MODSEC-375) Errors on compiling with NGINX on Amazon Linux

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-375.
--------------------------------------

    Fix Version/s: 2.7.2
                       (was: 2.7.0)
       Resolution: Fixed

> Errors on compiling with NGINX on Amazon Linux
> ----------------------------------------------
>
>                 Key: MODSEC-375
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-375
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Build System
>    Affects Versions: 2.7.0
>         Environment: EL6 x86_64, GCC 4.4.6
>            Reporter: Franklin Wise
>            Assignee: Breno Silva Pinto
>            Priority: High
>             Fix For: 2.7.2
>
>         Attachments: make.log
>
>
> It seems impossible to compile mod_security with NGINX on a CentOS 6 x86_64 machine with GCC 4.4.6. I've tried various NGINX versions from 1.2.0 to 1.2.4, the mod_security SVN trunk and also the latest downloadable RC release, following the instructions on: http://www.modsecurity.org/projects/modsecurity/nginx/index.html
> Log: http://pastebin.com/B3YA555R
> Someone from the mailing list has the same issue: http://sourceforge.net/mailarchive/forum.php?thread_name=CAD4%3DBrkSMV4bJSAceDCb6nkWPCV4S06-oLf3yufW4yYxi2E-cA%40mail.gmail.com&forum_name=mod-security-users

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Mod-security-developers] integrating ModSecurity with ReverseProxy

[Rolling S. <jz...@ho...>]

I am searching for technical guidance and directions on how can ModSecurity
be integrated with 3rd party Reverse Proxy.

 

Is this doable just using the same shim layer interface(api.h) to hook up
Proxy for each phase(5) that being used in IIS and Nginx integration? 

What are the pros and cons by doing so? 

 

Thank you,

[Mod-security-developers] [JIRA] Resolved: (MODSEC-378) make install Error with modsecurity-apache_2.7.1

[Breno S. P. (JIRA) <no...@mo...>]

     [ https://www.modsecurity.org/tracker/browse/MODSEC-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Breno Silva Pinto resolved MODSEC-378.
--------------------------------------

    Resolution: Fixed

> make  install Error with modsecurity-apache_2.7.1
> -------------------------------------------------
>
>                 Key: MODSEC-378
>                 URL: https://www.modsecurity.org/tracker/browse/MODSEC-378
>             Project: ModSecurity
>          Issue Type: Bug
>      Security Level: Normal
>          Components: Configuration
>    Affects Versions: 2.7.1
>         Environment: UAT
>            Reporter: Ananth N
>            Assignee: Breno Silva Pinto
>            Priority: High
>              Labels: modsecurity-apache_2.7.1
>             Fix For: 2.7.2
>
>         Attachments: configureAndMake.txt
>
>
> Hi 
> I am tring to Installation of modsecurity-apache_2.7.1 in my apache server and getting the follwing message when I try to execute the follwing 
> /usr/ccs/bin/make  install
> Can some one help me to fix this, thanks in advance.
> ERROR:
> Making install in tools
> test -z "/usr/local/modsecurity/bin" || ../build/install-sh -c -d "/usr/local/modsecurity/bin"
>  ../build/install-sh -c rules-updater.pl '/usr/local/modsecurity/bin'
> Making install in apache2
> test -z "/usr/local/modsecurity/lib" || ../build/install-sh -c -d "/usr/local/modsecurity/lib"
>  /bin/bash ../libtool   --mode=install ../build/install-sh -c   mod_security2.la '/usr/local/modsecurity/lib'
> libtool: install: ../build/install-sh -c .libs/mod_security2.so /usr/local/modsecurity/lib/mod_security2.so
> libtool: install: chmod +x /usr/local/modsecurity/lib/mod_security2.so
> libtool: install: ../build/install-sh -c .libs/mod_security2.lai /usr/local/modsecurity/lib/mod_security2.la
> libtool: install: ../build/install-sh -c .libs/mod_security2.a /usr/local/modsecurity/lib/mod_security2.a
> libtool: install: chmod 644 /usr/local/modsecurity/lib/mod_security2.a
> libtool: install: ranlib /usr/local/modsecurity/lib/mod_security2.a
> ----------------------------------------------------------------------
> Libraries have been installed in:
>    /usr/local/modsecurity/lib
> If you ever happen to want to link against installed libraries
> in a given directory, LIBDIR, you must either use libtool, and
> specify the full pathname of the library, or use the `-LLIBDIR'
> flag during linking and do at least one of the following:
>    - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
>      during execution
>    - use the `-RLIBDIR' linker flag
> See any operating system documentation about shared libraries for
> more information, such as the ld(1) and ld.so(8) manual pages.
> ----------------------------------------------------------------------
> /usr/ccs/bin/make  install-exec-hook
> Removing unused static libraries...
> usage: install [options] file [dir1 ...]
> *** Error code 2
> The following command caused the error:
> echo "Removing unused static libraries..."; \
> for m in mod_security2.la; do \
>   base=`echo $m | sed 's/\..*//'`; \
>   rm -f /usr/local/modsecurity/lib/$base.*a; \
>   install -D -m444 /usr/local/modsecurity/lib/$base.so ; \
> done
> make: Fatal error: Command failed for target `install-exec-hook'
> Current working directory /data/sdf/Temp/modsecurity/modsecurity-apache_2.7.1/apache2
> *** Error code 1
> make: Fatal error: Command failed for target `install-exec-am'
> Current working directory /data/sdf/Temp/modsecurity/modsecurity-apache_2.7.1/apache2
> *** Error code 1
> The following command caused the error:
> /usr/ccs/bin/make  install-exec-am install-data-am
> make: Fatal error: Command failed for target `install-am'
> Current working directory /data/sdf/Temp/modsecurity/modsecurity-apache_2.7.1/apache2
> *** Error code 1
> The following command caused the error:
> fail= failcom='exit 1'; \
> for f in x $MAKEFLAGS; do \
>   case $f in \
>     *=* | --[!k]*);; \
>     *k*) failcom='fail=yes';; \
>   esac; \
> done; \
> dot_seen=no; \
> target=`echo install-recursive | sed s/-recursive//`; \
> list='tools apache2 mlogc tests'; for subdir in $list; do \
>   echo "Making $target in $subdir"; \
>   if test "$subdir" = "."; then \
>     dot_seen=yes; \
>     local_target="$target-am"; \
>   else \
>     local_target="$target"; \
>   fi; \
>   (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && /usr/ccs/bin/make  $local_target) \
>   || eval $failcom; \
> done; \
> if test "$dot_seen" = "no"; then \
>   /usr/ccs/bin/make  "$target-am" || exit 1; \
> fi; test -z "$fail"
> make: Fatal error: Command failed for target `install-recursive'

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira