mod-security-developers — Development discussion about mod_security

Re: [Mod-security-developers] Macro expansion in operators

[Marc S. <mar...@ap...>]

The main goal is to be able to extend a pattern incrementally. This is especially useful in shared environments, but not limited to this case.

Example: you define you general policy to accept only certain characters
   SecRule ARGS "@validateByteRange 32-90"

In a location, you want an exception to accept some additional characters (CR/LF):
   <Location /...>
    SecRule ARGS "@validateByteRange 10,13,32-90"
   </Location>

In case you extend your global policy (let's say 32-95), your exception doesn't follow it. You are obliged to keep them aligned (you'll forget to do this if they are disseminated in several files).

The solution could be:
   SecAction "phase:1,setvar:tx.allowedRange=32-90"

   <Location /...>
    SecAction "phase:2,setvar:tx.allowedRange=%{tx.allowedRange},10,13"
   </Location>

   SecRule ARGS "@validateByteRange %{tx.allowedRange}" "phase:2,..."

Same for ipMatch

Marc

On 05-02-19 17:54, Felipe Costa wrote:

Hi Marc,


There is no specific reason. As there is a computational cost for macro expansion, we may have it only where/when it is extremely necessary. Do you have a specific use case?


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity


________________________________
From: Marc Stern <mar...@ap...><mailto:mar...@ap...>
Sent: Friday, February 1, 2019 12:16:20 PM
To: mod...@li...<mailto:mod...@li...>
Subject: [Mod-security-developers] Macro expansion in operators

Can somebody explain me why the operators below don't perform macro
expansion; they're using plain strings, not pre-calculated patterns:
  - ipMatch
  - validateByteRange

Would a pull request implementing this be accepted?

Marc Stern

_______________________________________________
mod-security-developers mailing list
mod...@li...<mailto:mod...@li...>
https://scanmail.trustwave.com/?c=4062&d=3bHU3PIPIuUQrzOmOziiUcqWOyJFIV2loAPuiTrUlA&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Macro expansion in operators

[Felipe C. <FC...@tr...>]

Hi Marc,


There is no specific reason. As there is a computational cost for macro expansion, we may have it only where/when it is extremely necessary. Do you have a specific use case?


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity

m: +55 81.98706.5547



[signature_480191669]

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services.<https://www.trustwave.com/company/about-us/accolades/>


________________________________
From: Marc Stern <mar...@ap...>
Sent: Friday, February 1, 2019 12:16:20 PM
To: mod...@li...
Subject: [Mod-security-developers] Macro expansion in operators

Can somebody explain me why the operators below don't perform macro
expansion; they're using plain strings, not pre-calculated patterns:
  - ipMatch
  - validateByteRange

Would a pull request implementing this be accepted?

Marc Stern

_______________________________________________
mod-security-developers mailing list
mod...@li...
https://scanmail.trustwave.com/?c=4062&d=3bHU3PIPIuUQrzOmOziiUcqWOyJFIV2loAPuiTrUlA&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

[Mod-security-developers] Macro expansion in operators

[Marc S. <mar...@ap...>]

Can somebody explain me why the operators below don't perform macro 
expansion; they're using plain strings, not pre-calculated patterns:
  - ipMatch
  - validateByteRange

Would a pull request implementing this be accepted?

Marc Stern

Re: [Mod-security-developers] Question about ARGS Variable

[Robert P. <rpa...@fe...>]

Hey Jai,

I believe ARGS is only filled with the request body with the request is a
urlencoded. Because ARGS and friends are treated as tabular variables,
ModSecurity won't attempt to parse an XML body and at it into the ARGS or
ARGS_POST variables, because there's no sane way to interpolate the
document into key-value paired data.

On Wed, Jan 2, 2019 at 10:21 AM Jai Harpalani via mod-security-developers <
mod...@li...> wrote:

> User-documentation states:
>
> "ARGS is a collection and can be used on its own (means all arguments
> including the POST Payload)..."
>
> Based on my testing, it does not appear that ARGS is including the POST
> payload. I am sending a POST request with the body shown below. I expect it
> to trigger Rule 930120, but it does not.
>
> Request Body:
>
> <?xml version='1.0' encoding='UTF-8'?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
> ">
>      <soapenv:Body>
>           <ns1:echo xmlns:ns1="http://example1.org/example1">
>                 <Text>hello .bashrc</Text>
>           </ns1:echo>
>      </soapenv:Body>
> </soapenv:Envelope>
>
> _______________________________________________
> 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] Question about ARGS Variable

[Jai H. <jai...@mu...>]

User-documentation states:

"ARGS is a collection and can be used on its own (means all arguments
including the POST Payload)..."

Based on my testing, it does not appear that ARGS is including the POST
payload. I am sending a POST request with the body shown below. I expect it
to trigger Rule 930120, but it does not.

Request Body:

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
     <soapenv:Body>
          <ns1:echo xmlns:ns1="http://example1.org/example1">
                <Text>hello .bashrc</Text>
          </ns1:echo>
     </soapenv:Body>
</soapenv:Envelope>

[Mod-security-developers] Announcement: ModSecurity version 2.9.3

[Victor H. <VH...@tr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

We are happy to announce ModSecurity version 2.9.3!

As previously announced, libModSecurity has reached official stable stage and was released for almost an year now. Therefore, new features and major improvements will be implemented only on version 3.x. Security or *major* bugs are planned to be back ported.

Still, in a effort to keep our commitment with the community, 2.9.3 still contains a number of improvements in different areas. These include, optimizations in the code, updating all dependencies, updating the embedded CRS version of the IIS build, clean ups, support for other architectures among other changes.

In addition to these improvements, a few key issues were fixed including mpm-itk / mod_ruid2 compatibility which was a roadblock for some CPANEL ModSecurity users and many other improvements focused on improving performance, usability and code resilience.

POTENTIAL SECURITY ISSUES:

 - Fix ip tree lookup on netmask content
   [@tinselcity]
- - potential off by one in parse_arguments
   [@tinselcity]

The complete list of changes is available on our change logs:
- - https://github.com/SpiderLabs/ModSecurity/releases/tag/v2.9.3

The source and binaries (and the respective hashes/signatures) are
available at:
- - https://github.com/SpiderLabs/ModSecurity/releases/tag/v2.9.3

The documentation for this release is available at:
- - https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29

The list of open issues is available on GitHub:
- - https://github.com/SpiderLabs/ModSecurity/labels/2.x

As with every new release, a milestone was created to host all the issues that will be fixed till we reach the given milestone. With that, we not only give the community the full transparency of the work that is being doing on ModSec, but also even more chances to participate. 
Milestones give the chance to anyone from the community to deduce when and what will be released. For instance the 2.9.4 milestone is in progress even before 2.9.3 milestone is closed.

Some of the active milestones from the ModSecurity project follows:

- - milestone v2.9.3: https://github.com/SpiderLabs/ModSecurity/milestone/10
- - milestone v2.9.4:
https://github.com/SpiderLabs/ModSecurity/milestone/14

Thanks to everybody who helped in this process: reporting issues, making comments and suggestions, sending patches and so on.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEENVJvmdv3xZcwKAX5LzS6oLmekUFAlwIAmoACgkQ5LzS6oLm
ekWTzQ//cIX68Y2HIBaR7nFvxsY199acxxKyJdoop3bVpJkZfBPUzgO7pUPGWPJj
LF3FD8yKqnNJkI2iArJqGWBCa4b9UQi01JLLWiiOdTRWOtHfU8miVOIKFD7nTRGj
DgNna1j8DEn8mrFcXyZctnhNfQu0Fp7sI2PLf5H4RyO58NpDyVxxquZwmLmc0ZQb
LIAz0td/pNl3O2anJzIimXusQe9qba/qqxC/W7W5ZqEBrqIR/UJ9s7qDxMaReyQ4
MGBvxxjqg3GLNV43v5M9RtaBcYTf3hT55AyG78MHqK+sZop+UhLUL+m6HU1F7FN/
4FvEfu/tq5ntHtCrh4xGk9JIbF4R7EdJEG9ruNbHZfKEPpJ5YNp2SScFRB/PQqAB
EL7wTetkKLpQiGPFEV6+W6vKV8BjTJFakEzdOojcELqmza/KslHMIlZoqcdwN1ln
iUxxeHW1txNWhfPvi8X1P6nxl10LaYTCHcUesHgjDvwhDgYX2FHYKwtALwVUgRVB
oOZjiyLpuMqNHDUdOBCkUlFIAxQj3EZ2ujORBXmD+SXhy5Su+S59hrT/iju37NgK
miwpbDNc1NwZQqoUSS+WG5W3TwqCCLzEcJIIwGqyW9K6HhM/Jyuadszvx5XzguyD
sZNz9cOmlSeGENJ5PMrEgVXN4v00k1FRpsqjErSlN3BlCglqpzY=
=F1hT
-----END PGP SIGNATURE-----

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Hegedüs E. <ai...@gm...>]

Hi Felipe,

On Fri, Nov 30, 2018 at 12:08:13PM +0000, Felipe Costa wrote:
> Hard to tell a precise date for 3.0.4. If not a trouble, I would recommend to keep it as a patch till we figure a precise date for the release.
> 
> The patches are:
>  - https://github.com/SpiderLabs/ModSecurity/commit/25bb1f1bcc7252e93bd42067cac23a07b71fb8b9.patch
>  - https://github.com/SpiderLabs/ModSecurity/commit/b736f0292dd24c53b1f54c027d022440791d9cc4.patch
>  - https://github.com/SpiderLabs/ModSecurity/commit/407b6c0f4bbeba519d998dad0e2e99c1c455e3c5.patch

thanks, I'll see these.


a.
 

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Felipe C. <FC...@tr...>]

Hard to tell a precise date for 3.0.4. If not a trouble, I would recommend to keep it as a patch till we figure a precise date for the release.

The patches are:
 - https://github.com/SpiderLabs/ModSecurity/commit/25bb1f1bcc7252e93bd42067cac23a07b71fb8b9.patch
 - https://github.com/SpiderLabs/ModSecurity/commit/b736f0292dd24c53b1f54c027d022440791d9cc4.patch
 - https://github.com/SpiderLabs/ModSecurity/commit/407b6c0f4bbeba519d998dad0e2e99c1c455e3c5.patch

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.
 
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>
 

On 11/30/18, 4:17 AM, "Ervin Hegedüs" <ai...@gm...> wrote:

    Hi Felipe,
    
    On Fri, Nov 30, 2018 at 12:55:03AM +0000, Felipe Costa wrote:
    > Hi guys,
    > 
    > 
    > I've made a few changes on the Regression utility to address this specific test case. As of now it should not fail because of the missing TERM variable.
    > 
    > 
    > Further details are listed here: https://scanmail.trustwave.com/?c=4062&d=guSA3O7QPc8uzz08a4jVWrEWtuNGo3cK_UDBmP5pkg&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fissues%2f1969
    
    sounds good,
    
    > Thank you.
    
    we thank you too.
    
    Just one question: as Alberto wrote in his first e-mail, the
    freeze date is soon.
    
    We can apply this modification only as Debian patch, if the 3.0.4
    will not released the dates. 
    
    What do you think, when will you release the new version?
    
    Here is the dates again:
    
    https://scanmail.trustwave.com/?c=4062&d=guSA3O7QPc8uzz08a4jVWrEWtuNGo3cK_UOQlKxrnA&s=5&u=https%3a%2f%2frelease%2edebian%2eorg%2fbuster%2ffreeze%5fpolicy%2ehtml
    
    The freeze for buster will happen according to the following
    timeline:
    
    * 2019-01-12 - Transition freeze
    * 2019-02-12 - Soft-freeze
    * 2019-03-12 - Full-freeze
    
    
    thanks,
    
    
    
    a.
    
    
    
    
    _______________________________________________
    mod-security-developers mailing list
    mod...@li...
    https://scanmail.trustwave.com/?c=4062&d=guSA3O7QPc8uzz08a4jVWrEWtuNGo3cK_UCXla4_zg&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
    ModSecurity Services from Trustwave's SpiderLabs:
    https://www.trustwave.com/spiderLabs.php
    

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Ervin H. <ai...@gm...>]

Hi Felipe,

On Fri, Nov 30, 2018 at 12:55:03AM +0000, Felipe Costa wrote:
> Hi guys,
> 
> 
> I've made a few changes on the Regression utility to address this specific test case. As of now it should not fail because of the missing TERM variable.
> 
> 
> Further details are listed here: https://github.com/SpiderLabs/ModSecurity/issues/1969

sounds good,

> Thank you.

we thank you too.

Just one question: as Alberto wrote in his first e-mail, the
freeze date is soon.

We can apply this modification only as Debian patch, if the 3.0.4
will not released the dates. 

What do you think, when will you release the new version?

Here is the dates again:

https://release.debian.org/buster/freeze_policy.html

The freeze for buster will happen according to the following
timeline:

* 2019-01-12 - Transition freeze
* 2019-02-12 - Soft-freeze
* 2019-03-12 - Full-freeze


thanks,



a.

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Felipe C. <FC...@tr...>]

Hi guys,


I've made a few changes on the Regression utility to address this specific test case. As of now it should not fail because of the missing TERM variable.


Further details are listed here: https://github.com/SpiderLabs/ModSecurity/issues/1969

Thank you.


Br.,

Felipe "Zimmerle" Costa

Security Researcher, Lead Developer ModSecurity



Trustwave | SMART SECURITY ON DEMAND

www.trustwave.com<http://www.trustwave.com/>



Recognized by industry analysts as a leader in managed security services<https://www.trustwave.com/Company/About-Us/Accolades/>.

________________________________
From: Alberto Gonzalez Iniesta <ag...@in...>
Sent: Wednesday, November 28, 2018 12:58:05 PM
To: mod...@li...
Subject: Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

Hi Felipe,

On Wed, Nov 28, 2018 at 02:21:54PM +0000, Felipe Costa wrote:
(snip)
>
> The test is important. It tests ModSec's ability to read environment variables. It is listed here:
> https://scanmail.trustwave.com/?c=4062&d=oK3-21UUBjG7oMuMkO03Vtc11mkAnKx18QaJ3G24Xg&s=5&u=https%3a%2f%2fgithub%2ecom%2fSpiderLabs%2fModSecurity%2fblob%2fv3%2fmaster%2ftest%2ftest-cases%2fregression%2fvariable-ENV%2ejson

Since the previous test case reads another one (PATH), it wasn't clear
to me if TERM was choosen for a particular reason.

> We may have poorly selected the name of the variable as it seems that the variable is not broadly used.
>
> (...)
>
>     Maybe the person that created the test case in the first place can
>     clarify the target of it.
>
> The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.
>
> I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.

Ok, I'll set the variable as Ervin suggested then.

> If setting the variable is a problem, I would prefer to change it to make it more broad available.
>
> A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant.

If setenv is used in the future it will save the packaging scripts from
setting it, thanks.

Thank you both for your help and clarification.

I hope we can trace the FAILures on the s390, ppc64 and sparc64 archs so
the package can start migrating to Debian Buster.

Regards,

Alberto

--
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://scanmail.trustwave.com/?c=4062&d=oK3-21UUBjG7oMuMkO03Vtc11mkAnKx18VOJjGjqWQ&s=5&u=http%3a%2f%2finittab%2ecom

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55


_______________________________________________
mod-security-developers mailing list
mod...@li...
https://scanmail.trustwave.com/?c=4062&d=oK3-21UUBjG7oMuMkO03Vtc11mkAnKx18QSK0GzqXQ&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Alberto G. I. <ag...@in...>]

Hi Felipe,

On Wed, Nov 28, 2018 at 02:21:54PM +0000, Felipe Costa wrote:
(snip)
>     
> The test is important. It tests ModSec's ability to read environment variables. It is listed here:
> https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-ENV.json

Since the previous test case reads another one (PATH), it wasn't clear
to me if TERM was choosen for a particular reason.

> We may have poorly selected the name of the variable as it seems that the variable is not broadly used.
> 
> (...)
> 
>     Maybe the person that created the test case in the first place can
>     clarify the target of it.
>     
> The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.
> 
> I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.

Ok, I'll set the variable as Ervin suggested then.

> If setting the variable is a problem, I would prefer to change it to make it more broad available.
> 
> A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant. 

If setenv is used in the future it will save the packaging scripts from
setting it, thanks.

Thank you both for your help and clarification.

I hope we can trace the FAILures on the s390, ppc64 and sparc64 archs so
the package can start migrating to Debian Buster.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Felipe C. <FC...@tr...>]

Hi Alberto,


On 11/27/18, 10:02 AM, "Alberto Gonzalez Iniesta" <ag...@in...> wrote:

    Hi Ervin!
    
    On Tue, Nov 27, 2018 at 12:21:28PM +0100, Ervin Hegedüs wrote:
  
(...)

    > 
    > https://scanmail.trustwave.com/?c=4062&d=_MD928s2E7_LLeYfmEvXduZalbOHdDL5LPg1bkTMNQ&s=5&u=https%3a%2f%2fsourceforge%2enet%2fp%2fmod-security%2fmailman%2fmessage%2f36455922%2f
    > 
    > But my question is: why is it better to completely disable the
    > test than my suggestion?
    
    As we already talked about, I'm not sure that playing with envvars in
    build daemons is such a good idea. And I'd like to know if that test is
    really useful. That's why I asked here again.
    
The test is important. It tests ModSec's ability to read environment variables. It is listed here:
https://github.com/SpiderLabs/ModSecurity/blob/v3/master/test/test-cases/regression/variable-ENV.json

We may have poorly selected the name of the variable as it seems that the variable is not broadly used.

(...)

    Maybe the person that created the test case in the first place can
    clarify the target of it.
    
The objective of the test is not to read the TERM variable, but any environment variable. Setting the variable before the test case execution, as Ervin suggested, seems to be a valid way of testing it.

I am not in favor disable the test case. I am aware that it is a single test among 5k+ test that we have today. But every test is there for a reason.

If setting the variable is a problem, I would prefer to change it to make it more broad available.

A possibility is to change the test utility to set a ModSecurity environment variable that will be further read by the test in question. Other possibility is to use setenv action to set a variable to be read. Fundamentally it has no difference form Ervin's suggestion, although it will be more elegant. 

Br.
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.
 
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Ervin H. <ai...@gm...>]

Hi Alberto,

On Tue, Nov 27, 2018 at 02:02:22PM +0100, Alberto Gonzalez Iniesta wrote:
> > > Hi,
> > > 
> > > The build daemons at Debian are failing the test suite for modsecurity
> > > 3.x. There are two failures I could use some help on:
> > > 
> > > 1) 
> > > ./regression_tests .././test/test-cases/regression/variable-ENV.json:1
> > > :test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)
> > > 
> > > My guess is that build daemon don't have the TERM variable set, and I'm
> > > pondering disabling this test unless someone claims this is a bad idea.
> > 
> > that's what I wrote you on mod-security-packagers list:
> > 
> > https://sourceforge.net/p/mod-security/mailman/message/36455922/
> > 
> > But my question is: why is it better to completely disable the
> > test than my suggestion?
> 
> As we already talked about, I'm not sure that playing with envvars in
> build daemons is such a good idea. And I'd like to know if that test is
> really useful. That's why I asked here again.

right - hope somebody will clarify / confirm or confute this, but
I think it's useful and important. I mean it is, but not for the
build environment, but the developers and production
environments.
 
> > * I've suggested a solution:
> > https://github.com/airween/ModSecurity/blob/90a09f3a7616ae8f4406a30d213bd971cf1c45bb/debian/rules#L9
> > * I'm sure that there are several other solution, eg: make a
> >   patch in debian/patches/ directory, which replaces the TERM
> >   variable for an another ENV variable, which exists in build
> >   system?
> 
> Maybe the person that created the test case in the first place can
> clarify the target of it.

let's see the rule, what's happening:
- ModSec wants to read an environment variable, short form ENV
- the name of variable is "TERM"
- ModSec checks if the variable contains the pattern "test"
- and finally, it doesn't care if it does :), because the action
  will pass always

I think this test case just _READ_ the ENV, it doesn't matter,
what's the content of it.

If it can't read, then it will fail.

As I wrote above, hope somebody will confirm it, but I think it
would be good to keep this test, and replace the ENV for
something what exists in build env, or setit up explicitly.



Regards,


a.
 

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Alberto G. I. <ag...@in...>]

Hi Ervin!

On Tue, Nov 27, 2018 at 12:21:28PM +0100, Ervin Hegedüs wrote:
> Hi Alberto,
> 
> On Tue, Nov 27, 2018 at 11:42:54AM +0100, Alberto Gonzalez Iniesta wrote:
> > Hi,
> > 
> > The build daemons at Debian are failing the test suite for modsecurity
> > 3.x. There are two failures I could use some help on:
> > 
> > 1) 
> > ./regression_tests .././test/test-cases/regression/variable-ENV.json:1
> > :test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)
> > 
> > My guess is that build daemon don't have the TERM variable set, and I'm
> > pondering disabling this test unless someone claims this is a bad idea.
> 
> that's what I wrote you on mod-security-packagers list:
> 
> https://sourceforge.net/p/mod-security/mailman/message/36455922/
> 
> But my question is: why is it better to completely disable the
> test than my suggestion?

As we already talked about, I'm not sure that playing with envvars in
build daemons is such a good idea. And I'd like to know if that test is
really useful. That's why I asked here again.

> * I've suggested a solution:
> https://github.com/airween/ModSecurity/blob/90a09f3a7616ae8f4406a30d213bd971cf1c45bb/debian/rules#L9
> * I'm sure that there are several other solution, eg: make a
>   patch in debian/patches/ directory, which replaces the TERM
>   variable for an another ENV variable, which exists in build
>   system?

Maybe the person that created the test case in the first place can
clarify the target of it.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Re: [Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Ervin H. <ai...@gm...>]

Hi Alberto,

On Tue, Nov 27, 2018 at 11:42:54AM +0100, Alberto Gonzalez Iniesta wrote:
> Hi,
> 
> The build daemons at Debian are failing the test suite for modsecurity
> 3.x. There are two failures I could use some help on:
> 
> 1) 
> ./regression_tests .././test/test-cases/regression/variable-ENV.json:1
> :test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)
> 
> My guess is that build daemon don't have the TERM variable set, and I'm
> pondering disabling this test unless someone claims this is a bad idea.

that's what I wrote you on mod-security-packagers list:

https://sourceforge.net/p/mod-security/mailman/message/36455922/

But my question is: why is it better to completely disable the
test than my suggestion?

* I've suggested a solution:
https://github.com/airween/ModSecurity/blob/90a09f3a7616ae8f4406a30d213bd971cf1c45bb/debian/rules#L9
* I'm sure that there are several other solution, eg: make a
  patch in debian/patches/ directory, which replaces the TERM
  variable for an another ENV variable, which exists in build
  system?

> 2) But the ones that are really beyond my understanding are those in:
> test/test-cases/secrules-language-tests/operators/ipMatch.json
> Failing in s390, ppc64 and sparc64. I suspect they may be related to
> endianness, but I really need help with those. You may find the build
> logs here [1].

I'll check that soon.

> If we get this solved quickly, modsecurity 3.x will be available in
> Debian's next release. [2]

please review the milestones:

https://github.com/SpiderLabs/ModSecurity/milestones

The next release had planned at Nov 08, 2019 - that's about a
year. Hope that's just a "plan" :).

But if the next release will not published till the freeze time,
you have to make the patches. I'll help you readily.


a.

[Mod-security-developers] Tests failing in some archs (s390x, ppc64, sparc64)

[Alberto G. I. <ag...@in...>]

Hi,

The build daemons at Debian are failing the test suite for modsecurity
3.x. There are two failures I could use some help on:

1) 
./regression_tests .././test/test-cases/regression/variable-ENV.json:1
:test-result: FAIL variable-ENV.json:Testing Variables :: ENV (2/3)

My guess is that build daemon don't have the TERM variable set, and I'm
pondering disabling this test unless someone claims this is a bad idea.

2) But the ones that are really beyond my understanding are those in:
test/test-cases/secrules-language-tests/operators/ipMatch.json
Failing in s390, ppc64 and sparc64. I suspect they may be related to
endianness, but I really need help with those. You may find the build
logs here [1].

If we get this solved quickly, modsecurity 3.x will be available in
Debian's next release. [2]


Thanks,

Alberto


[1]
https://buildd.debian.org/status/fetch.php?pkg=modsecurity&arch=s390x&ver=3.0.2-1&stamp=1539707222&raw=0
https://buildd.debian.org/status/fetch.php?pkg=modsecurity&arch=ppc64&ver=3.0.2-1&stamp=1540024601&raw=0
https://buildd.debian.org/status/fetch.php?pkg=modsecurity&arch=sparc64&ver=3.0.2-1&stamp=1539704551&raw=0

[2] https://release.debian.org/buster/freeze_policy.html
-- 
Alberto Gonzalez Iniesta    | Formación, consultoría y soporte técnico
mailto/sip: ag...@in... | en GNU/Linux y software libre
Encrypted mail preferred    | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

[Mod-security-developers] Will ModSecurity Block in Detection-Only Mode?

[Alexandr S. <ale...@gm...>]

Hi everyone,

I reading now "Ivan Ristic - ModSecurity Handbook (2010)".

On page 34 it's state that Detection-Only blocks traffic depending on
the directives:
 
SecRequestLimit, 
SecRequestNoFilesLimit, 
SecResponseBodyLimit.

At this page is also states that this is expected to be fixed in
version 2.6.

Now I using v3/master. Is it fixed?


Thanks.

Regards,

[Mod-security-developers] Protection against Bash injection

[Marc S. <mar...@ap...>]

For those who remember, we (Approach Belgium) published in 2011 the "cmdLine" transformation that handles most Windows cmd injections (and some basic bash injections). The "cmdLine" transformation is now officially part of ModSecurity for years.

We were also using, to protect our customers for some years, an additional transformation blocking several other bash injections.
We decided to also give it to the community.
The source code and the explanations are available on https://www.approach.be/en/modsecurity.html


Enjoy

[cid:par...@ap...]       Marc Stern
Cyber-Security Consulting Director
Approach Belgium<https://www.approach.be>
Axis Park - Rue Edouard Belin 7 - 1435 Mont-Saint-Guibert - Belgium
Follow us: [cid:par...@ap...] <https://www.linkedin.com/company/16513/>    [cid:par...@ap...] <https://twitter.com/ApproachBe>
Inspiring the cyber-security community


This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please contact the sender and delete this message and any attachment from your system. Unauthorised publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited.

[Mod-security-developers] ModSecurity version 3.0.3 announcement

[Felipe C. <FC...@tr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It is a pleasure to announce the release of ModSecurity version 3.0.3
(libModSecurity). This version contains a number of improvements in different
areas. These include, clean ups, better practices for improved code
readability, resilience and overall performance.

In addition to these improvements, support to a few missing features such as
SecRuleUpdateTargetById, SecRuleUpdateActionById, full support to
ctl:requestBodyProcessor and other versions of Lua, (including LuaJIT) as well
as fixes on other actions and transformations that were also added since 3.0.2
was released.

The API now supports the ability to have the unique id informed on
transactions, making possible to match an id that it is already in use by the
consuming application (the connector).

Special thanks to @tinselcity who pointed us to an uneducated memory usage that
could lead to a security issue.

The list with the full changes can be found on the project CHANGES file,
available here:
 - https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.3/CHANGES

The list of open issues is available on GitHub:
 - https://github.com/SpiderLabs/ModSecurity/labels/3.x

As with every new release, a milestone was created to host all the issues that
will be fixed till we reach the given milestone. With that, we not only give
the community the full transparency of the work that is being done on ModSec,
but also even more chances to participate.
Milestones give the chance to anyone from the community to deduce when and what
will be released. For instance the 3.0.4 milestone is in progress even before
3.0.3 milestone is closed.

Some of the active milestones from the ModSecurity project follows:

- - milestone v3.0.3: https://github.com/SpiderLabs/ModSecurity/milestone/12
- - milestone v3.0.4: https://github.com/SpiderLabs/ModSecurity/milestone/13

Thanks to everybody who helped in this process: reporting issues, making
comments and suggestions, sending patches and so on.

Further details on the compilation process for ModSecurity v3, can be found on
the project README:
 - https://github.com/SpiderLabs/ModSecurity/tree/v3/master#compilation

Complementary documentation for the connectors are available here:
 - nginx: https://github.com/SpiderLabs/ModSecurity-nginx/#compilation
 - Apache: https://github.com/SpiderLabs/ModSecurity-apache/#compilation

IMPORTANT: ModSecurity version 2 will be available and maintained parallel to
version 3. There is no ETA to deprecate the version 2.x. New features and major
improvements will be implemented on version 3.x. Security or major bugs are
planned to be back ported. Version 2 and version 3 has a completely independent
development/release cycle.


Br.,
Felipe "Zimmerle" Costa
Security Researcher, Lead Developer ModSecurity

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com

Recognized by industry analysts as a leader in managed security services.



-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iF0EARECAB0WIQQZDvrMoen6RmqOzZzm37CM6LESdwUCW+Co8AAKCRDm37CM6LES
d8zdAJsEDkLqG9POMF4kIt9vliPL69AxCgCfdIzGiiDtoxGPejBwPgCYN+CidMM=
=OTGt
-----END PGP SIGNATURE-----

[Mod-security-developers] modsecurity iis always return 500 status code

[곽민 <mi...@gm...>]

I was install modsecurity 2.9.2  in windows server 2016 / iis 10

Core rule set version is 2.2.9

When i tested in php page, modsecurity successfully block matched rule
traffic,

but log is always 500(internal server error)(Regardless of pass or block)

I think modsecurity can't get status code because status code in audit log
always '0'
example log : WIN-EU34NTQNDKV 192.168.1.6 - - [11/Sep/2018:12:20:44 +0900]
"GET /dvwa/vulnerabilities/sqli/ HTTP/1.1" 0 0 "-" "-" 17798225733810651262
"-" /20180911/20180911-1220/20180911-122044-17798225733810651262 0 1019
md5:749962ae19cfa1b79a228f97305c2b3c

so i add SecstreamInBodyInspection On and SecRequestBodyAccess On

and also disable dynamic content and static content compression

But status code 500,

How to fix that?

thanks~

Re: [Mod-security-developers] Security issue management

[Felipe C. <FC...@tr...>]

You not only got a reply but we discuss on GitHub about it: https://github.com/SpiderLabs/ModSecurity/issues/1576

Br.,
Felipe “Zimmerle” Costa
Security Researcher, Lead Developer ModSecurity.
 
Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>
 

On 9/5/18, 8:00 AM, "Marc Stern" <mar...@ap...> wrote:

    Hello,
    
    I reported a security issue one month ago and I never got any answer.
    Is anybody monitory the mailbox sec...@mo...?
    I copied Victor Hora & Felipe Costa one week ago and no feedback.
    Did I miss something?
    
    Marc
    
    ------------------------------------------------------------------------------
    Check out the vibrant tech community on one of the world's most
    engaging tech sites, http://scanmail.trustwave.com/?c=4062&d=sreP28WPopHX3dh8_ArMOBQj0C8ZnSda-mrLhIHDLA&s=5&u=http%3a%2f%2fSlashdot%2eorg%21 http://scanmail.trustwave.com/?c=4062&d=sreP28WPopHX3dh8_ArMOBQj0C8ZnSda-jyYgoXFKA&s=5&u=http%3a%2f%2fsdm%2elink%2fslashdot
    _______________________________________________
    mod-security-developers mailing list
    mod...@li...
    https://scanmail.trustwave.com/?c=4062&d=sreP28WPopHX3dh8_ArMOBQj0C8ZnSda-mvPiIOQew&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistinfo%2fmod-security-developers
    ModSecurity Services from Trustwave's SpiderLabs:
    https://www.trustwave.com/spiderLabs.php
    

[Mod-security-developers] Security issue management

[Marc S. <mar...@ap...>]

Hello,

I reported a security issue one month ago and I never got any answer.
Is anybody monitory the mailbox sec...@mo...?
I copied Victor Hora & Felipe Costa one week ago and no feedback.
Did I miss something?

Marc

[Mod-security-developers] Goal of function of collection

[Ervin H. <ai...@gm...>]

Hi there,

there were some issue and its resolved PR on Github:

https://github.com/SpiderLabs/ModSecurity/issues/1808

https://github.com/SpiderLabs/ModSecurity/pull/1810
"Fix variables case sensitiveness"

At this issue/PR somebody has referenced the manual:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#setvar

"setvar

Description: Creates, removes, or updates a variable. Variable
names are case-insensitive."

I've re-read the discussions, manual, and code, especially the
src/collection/backend/in_memory-per_process.cc and lmdb.cc.

Both classes have a function: resolveMultiMatches(), which is (if I
interpret as right way) looks up the key in the collection, and
if it found (one or more times) it gives back them in a Vector.

But what's the goal of this function, if the variable names are
case-insensitive? I think the backend (at this time only the
in_memory-per_process.cc) gives back always the same variable,
no matter how did we referenced, eg. "something", "Something" or
"somethinG". The lenght of vector always will be 1...

It would be enough a resolveSingleMatch() - but it never called
(I just checked it with regresion/collection-tx.json through
gdb).


Any idea?


Thanks,


a.

Re: [Mod-security-developers] Crash in msc_rules_add_file in v3.0.2

[Robert P. <rp...@li...>]

Thanks, I'll do that.

Bob

On Wed, Jul 25, 2018 at 12:00 PM, Robert Paprocki <
rpa...@fe...> wrote:

> Bob,
>
> Probably best to open a Github issue at https://github.com/
> Spiderlabs/Modsecurity/issues so this can be tracked?
>
> On Wed, Jul 25, 2018 at 8:29 AM, Robert Perper <rp...@li...>
> wrote:
>
>> Hi, my name is Bob Perper and I'm a developer here at LiteSpeed
>> technologies.  We include a connector for ModSecurity v3.0 in our new
>> release of OpenLiteSpeed and have an error reported by a customer that when
>> we reproduced it, resulted in a crash.
>>
>> The customer was using the Comodo rulesset and was reporting errors like
>> this one:
>>
>>     "/usr/local/lsws/conf/modsec/comodo/05_Global_Exceptions.conf
>> failed, ret -1, reason: 'Rules error. File: /usr/local/lsws/conf/modsec/comodo/02_Global_Generic.conf.
>> Line: 70. Column: 18. Rule id: 0 is duplicated
>> Rules error. File: /usr/local/lsws/conf/modsec/co
>> modo/05_Global_Exceptions.conf. Line: 16. Column: 88. Expecting an
>> action, got:  ,t:none"'."
>>
>> So we downloaded the Comodo files and tried it on our system with our
>> connector and got similar but not exact errors.  So we isolated one
>> specific file (03_Global_Agents.conf), used it and commented out a long
>> line rule (two lines, line 30 and 31), (file is attached).  When we run
>> openlitespeed in the debugger we call 'msc_rules_add_file' on this file,
>> the code crashes in ModSecurity/src/rule.cc:137
>>
>> So since we were skeptical about this and figured it might be a bug in
>> OpenLiteSpeed.  So we installed Open NGINX and using their connector set up
>> a similar rule.  With the exact same file, it crashed in the same call.
>>
>> We tried the same action with the master branch and had the same
>> results.  Feel free to contact me directly if you have any additional
>> questions.
>>
>> Thanks,
>>
>> --
>> Bob Perper
>> rp...@li...
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> 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
>>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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
>



-- 
Bob Perper
rp...@li...

Re: [Mod-security-developers] Crash in msc_rules_add_file in v3.0.2

[Robert P. <rpa...@fe...>]

Bob,

Probably best to open a Github issue at
https://github.com/Spiderlabs/Modsecurity/issues so this can be tracked?

On Wed, Jul 25, 2018 at 8:29 AM, Robert Perper <rp...@li...>
wrote:

> Hi, my name is Bob Perper and I'm a developer here at LiteSpeed
> technologies.  We include a connector for ModSecurity v3.0 in our new
> release of OpenLiteSpeed and have an error reported by a customer that when
> we reproduced it, resulted in a crash.
>
> The customer was using the Comodo rulesset and was reporting errors like
> this one:
>
>     "/usr/local/lsws/conf/modsec/comodo/05_Global_Exceptions.conf failed,
> ret -1, reason: 'Rules error. File: /usr/local/lsws/conf/modsec/comodo/02_Global_Generic.conf.
> Line: 70. Column: 18. Rule id: 0 is duplicated
> Rules error. File: /usr/local/lsws/conf/modsec/
> comodo/05_Global_Exceptions.conf. Line: 16. Column: 88. Expecting an
> action, got:  ,t:none"'."
>
> So we downloaded the Comodo files and tried it on our system with our
> connector and got similar but not exact errors.  So we isolated one
> specific file (03_Global_Agents.conf), used it and commented out a long
> line rule (two lines, line 30 and 31), (file is attached).  When we run
> openlitespeed in the debugger we call 'msc_rules_add_file' on this file,
> the code crashes in ModSecurity/src/rule.cc:137
>
> So since we were skeptical about this and figured it might be a bug in
> OpenLiteSpeed.  So we installed Open NGINX and using their connector set up
> a similar rule.  With the exact same file, it crashed in the same call.
>
> We tried the same action with the master branch and had the same results.
> Feel free to contact me directly if you have any additional questions.
>
> Thanks,
>
> --
> Bob Perper
> rp...@li...
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> 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
>