mod-security-developers — Development discussion about mod_security

Re: [Mod-security-developers] ModSec + NGINX bug in move_brigade_to_chain

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

Hi Carlos,

In the same issue that you have linked, there is a comment pointing to the "nginx_refactoring" branch where you can find this fix and others.
The branch still in development/test as more minor issues should be fixed before merge it to our mainline.

Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>



From: Carlos Vidal <ca...@ta...<mailto:ca...@ta...>>
Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Tuesday, July 8, 2014 2:20 PM
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: [Mod-security-developers] ModSec + NGINX bug in move_brigade_to_chain

Hi:

I'm testing ModSec 2.7.5 and 2.8.0 with NGINX and find a problem when SecResponseBodyAccess is turned on.

The error is produced by a dangling pointer in move_brigade_to_chain() (apr_bucket_nginx.c). It has already been reported in March (https://github.com/SpiderLabs/ModSecurity/issues/681).

There are two ngx_alloc_chain_link() in the function, the second is correct, but the first one does not initialize 'cl->next' before copying it to the last link (ll). It is enough to add :

   cl->next = NULL;

just after cl->buf->last_buf = 1.

This causes crazy behavior as infinite allocation loops and seg-faults.


________________________________

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] ModSec + NGINX bug in move_brigade_to_chain

[Carlos V. <ca...@ta...>]

Hi:

I'm testing ModSec 2.7.5 and 2.8.0 with NGINX and find a problem when
SecResponseBodyAccess is turned on.

The error is produced by a dangling pointer in move_brigade_to_chain()
(apr_bucket_nginx.c). It has already been reported in March (
https://github.com/SpiderLabs/ModSecurity/issues/681).

There are two ngx_alloc_chain_link() in the function, the second is
correct, but the first one does not initialize 'cl->next' before copying it
to the last link (ll). It is enough to add :

   cl->next = NULL;

just after cl->buf->last_buf = 1.

This causes crazy behavior as infinite allocation loops and seg-faults.

Re: [Mod-security-developers] Mutex lock issue with modsecurity + nginx + apr

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

Hi,

We have an open issue for that specific problem, it is available here:
https://github.com/SpiderLabs/ModSecurity/issues/674


Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

From: prdevel006 <prd...@gm...<mailto:prd...@gm...>>
Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Wednesday, July 2, 2014 7:55 AM
To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Subject: [Mod-security-developers] Mutex lock issue with modsecurity + nginx + apr

I am using modsecurity with nginx it always crashes when i turn on audit logging as its unable to find the mutex [apr_global_mutex_create() not returning the mutex].Whey apr is unable to get the mutex is there any specific reason for this. Is this an issue of modsecurity or APR module.



________________________________

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.

Re: [Mod-security-developers] help me!pls

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

Hi Jarwin,

ModSecurity uses this Apr Memory Pool to handle the memory management, for further information:
 - http://en.wikipedia.org/wiki/Apache_Portable_Runtime
 - http://www.apachetutor.org/dev/pools


Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>


From: 蕴涵 <252...@qq...<mailto:252...@qq...>>
Reply-To: "mod...@li...<mailto:mod...@li...>" <mod...@li...<mailto:mod...@li...>>
Date: Tuesday, July 1, 2014 12:47 PM
To: mod-security-developers <mod...@li...<mailto:mod...@li...>>
Subject: [Mod-security-developers] help me!pls

hi:
     I ran into a problem when read modsecurity-2.7.7 source code，when http request came，modsecurity will executive function(create_tx_context()),In this fuction call
apr_allocator_create(&allocator)，but I cann't find any apr_allocator_free() fuction or apr_allocator_destroy() function to release allocator memory，The program will not cause memory leaks? if not，when does modsecurity  release memory? I can not sleep wellbecause of this puzzle problem！pls reply me！！

Thanks
                                jarwin

________________________________

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] Mutex lock issue with modsecurity + nginx + apr

[prdevel006 <prd...@gm...>]

I am using modsecurity with nginx it always crashes when i turn on audit
logging as its unable to find the mutex [apr_global_mutex_create() not
returning the mutex].Whey apr is unable to get the mutex is there any
specific reason for this. Is this an issue of modsecurity or APR module.

[Mod-security-developers] help me!pls

[蕴涵 <252...@qq...>]

hi:
     I ran into a problem when read modsecurity-2.7.7 source code，when http request came，modsecurity will executive function(create_tx_context()),In this fuction call ‍
apr_allocator_create(&allocator)，but I cann't find any apr_allocator_free() fuction or apr_allocator_destroy() function to release allocator memory，The program will not cause memory leaks? if not，when does modsecurity  release memory? ‍I can not sleep well because of this puzzle problem！pls reply me！！‍


Thanks
                                jarwin

[Mod-security-developers] Bug #391

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

This bug was closed but it is not correctly fixed.
I proposed a (trivial) patch - I cannot reopen the issues.

Ryan, can you reopen it and have it fixed.

Thanks

[Mod-security-developers] File type inspection

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

Hello,

I'd like implement a filter to determine uploaded files type (think 
about the "file" command under Unix).
Obviously, I could use the "@InspectFile" operator with a script but it 
has 2 drawbacks:
    - launching a new process every time is slow
    - you cannot parametrise the type of files you allow except by 
hard-coding them in the script(s) - maybe by using environment
variables, but what side-effects can we have when launching several 
scripts with different allowed types?
So, I think a filter returning the file type is the best approach - you 
can decide then if you accept it or not.
Is there any better way I didn't think about?

Question: How to access the file content?
The easiest way is to probably to open the file on the disk (like in 
@InspectFile) but
1. Can't we access the data in memory directly? This should be more 
performant. How to access only the file content from a multipart 
parameter - do we have to parse it manually?
2. Although we can block the request, the file will already have been 
written on the disk. Do we have to remove it with a @InspectFile script?
Is there any way to block before the file was written to disk (as we 
only have to read a few bytes of it) ?

I'm waiting for your ideas and I'll open a GitHub Issue once I have a 
better view.

Marc Stern
Approach Belgium - www.approach.be

Re: [Mod-security-developers] sanitiseArgs not working with JSON payload

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

Hi Bruno,

On Apr 29, 2014, at 8:27 AM, Bruno Savioli de Almeida <br...@sa...<mailto:br...@sa...>> wrote:

Hi,

I'm testing 2.8.0 with the JSON request body processor and it seems that the sanitiseArgs is not working as expected.


Thanks for the report.

I've just created an issue on github with your description:
https://github.com/SpiderLabs/ModSecurity/issues/715


Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>


________________________________

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.

Re: [Mod-security-developers] segfaults on JSON request body processor

[Bruno S. de A. <br...@sa...>]

Hi Felipe,

Apologies for the delay, I was on away for a while.

I'm currently testing 2.8.0 and most of the JSON stuff seems to be working
ok. Found one minor issue with sanitiseArgs that I'll post on a new email.

Thanks for your help.

Bruno


On 20 March 2014 18:25, Felipe Costa <FC...@tr...> wrote:

>  Hi Bruno,
>
>  Thanks for the detailed debugging information. I have just made some
> modifications on the code in order to fix the problem. The branch
> json_top_of_2_7_7 no longer exists, I would like to ask you to test the
> branch json instead:
>
>  https://github.com/SpiderLabs/ModSecurity/tree/json
>
>  This new branch does not only contains this specific bugfix but it is
> up-to-date with our master branch.
>
>  Thanks,
>   *Felipe "Zimmerle" Costa*
>  Security Researcher, SpiderLabs
>
>  *Trustwave* | SMART SECURITY ON DEMAND
>  www.trustwave.com
>
>
>  On Feb 13, 2014, at 8:07 AM, Bruno Savioli <br...@sa...> wrote:
>
>  Hi Felipe,
>
>  Thanks for the instructions.
>
>  Here's the output of 'bt full', hope it helps.
>
>
>  Program received signal SIGSEGV, Segmentation fault.
> __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:213
> 213 movlpd (%rdi), %xmm1
> Missing separate debuginfos, use: debuginfo-install
> cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-18.el6_4.x86_64
> expat-2.0.1-11.el6_2.x86_64 keyutils-libs-1.4-4.el6.x86_64
> krb5-libs-1.10.3-10.el6_4.6.x86_64 libcom_err-1.41.12-18.el6.x86_64
> libselinux-2.0.94-5.3.el6_4.1.x86_64 libuuid-2.17.2-12.14.el6.x86_64
> libxml2-2.7.6-14.el6.x86_64 lua-5.1.4-4.1.el6.x86_64
> nspr-4.10.2-1.el6_5.x86_64 nss-3.15.3-3.el6_5.x86_64
> nss-softokn-freebl-3.14.3-9.el6.x86_64 nss-util-3.15.3-1.el6_5.x86_64
> openldap-2.4.23-32.el6_4.1.x86_64 openssl-1.0.1e-16.el6_5.4.x86_64
> pcre-7.8-6.el6.x86_64 zlib-1.2.3-29.el6.x86_64
> (gdb)
> (gdb) bt full
> #0  __strcmp_sse2 () at ../sysdeps/x86_64/strcmp.S:213
> No locals.
> #1  0x00007ffff2b81f7c in sec_audit_logger (msr=0x7ffff8d1da80) at
> msc_logging.c:699
>         arg = 0x7ffff8d47fa8
>         sorted_args = 0x7ffff8d5ba68
>         nextarg = 0x0
>         tarr = 0x7ffff8d39640
>         telts = 0x7ffff8d39768
>         offset = 0
>         last_offset = 0
>         sanitize = 0
>         my_error_msg = 0x0
>         arr = 0x7ffff8d48250
>         te = 0x7ffff8d48378
>         tarr_pattern = 0x7ffff8d33b68
>         telts_pattern = 0x7ffff8d33c90
>         str1 = 0x0
>         str2 = 0x0
>         text = 0x7ffff8d5ba50 "Content-Length: 133\n"
>         rule = 0x0
>         next_rule = 0x0
>         nbytes = 0
>         nbytes_written = 140737368015808
>         md5hash =
> "\000\000\000\000\000\000\000\000\330\301\323\370\377\177\000"
>         was_limited = 0
>         present = 0
>         wrote_response_body = 0
>         entry_filename = 0xf8d3ba88 <Address 0xf8d3ba88 out of bounds>
>         entry_basename = 0x7fffffffdc90 "h\272\325\370\377\177"
>         rc = 0
>         i = 0
>         limit = -132113904
>         k = 32767
>         sanitized_partial = 0
>         j = 32767
>         buf = 0x0
>         pat = 0x0
>         mparm = 0x0
>         arg_min = 32767
>         arg_max = -120464768
>         sanitize_matched = 0
> #2  0x00007ffff2b79225 in modsecurity_process_phase_logging
> (msr=0x7ffff8d1da80) at modsecurity.c:695
>         time_before = 1392288967111028
>         time_after = 1392288967111070
> #3  0x00007ffff2b794b5 in modsecurity_process_phase (msr=0x7ffff8d1da80,
> phase=5) at modsecurity.c:801
> No locals.
> #4  0x00007ffff2b77190 in hook_log_transaction (r=0x7ffff8d1c1f8) at
> mod_security2.c:1217
>         arr = 0x7ffff8d5e0a0
>         origr = 0x7ffff8d1c1f8
> ---Type <return> to continue, or q <return> to quit---
>         msr = 0x7ffff8d1da80
> #5  0x00007ffff7fc8600 in ap_run_log_transaction (r=0x7ffff8d1c1f8) at
> /usr/src/debug/httpd-2.2.15/server/protocol.c:1705
>         pHook = <value optimized out>
>         n = <value optimized out>
>         rv = <value optimized out>
> #6  0x00007ffff7fe5a7f in ap_process_request (r=0x7ffff8d1c1f8) at
> /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:308
>         access_status = <value optimized out>
> #7  0x00007ffff7fe29a8 in ap_process_http_connection (c=0x7ffff8cadcf8) at
> /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
>         r = 0x7ffff8d1c1f8
>         csd = 0x0
> #8  0x00007ffff7fde6b8 in ap_run_process_connection (c=0x7ffff8cadcf8) at
> /usr/src/debug/httpd-2.2.15/server/connection.c:43
>         pHook = <value optimized out>
>         n = <value optimized out>
>         rv = <value optimized out>
> #9  0x00007ffff7fea977 in child_main (child_num_arg=<value optimized out>)
> at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
>         current_conn = <value optimized out>
>         csd = 0x7ffff8cadb08
>         ptrans = 0x7ffff8cada88
>         allocator = 0x7ffff8cab980
>         status = <value optimized out>
>         i = <value optimized out>
>         lr = <value optimized out>
>         pollset = 0x7ffff8cabc20
>         sbh = 0x7ffff8cabc18
>         bucket_alloc = 0x7ffff8d14148
>         last_poll_idx = 1
> #10 0x00007ffff7feac46 in make_child (s=0x7ffff8212880, slot=0) at
> /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:707
>         pid = <value optimized out>
> #11 0x00007ffff7feb293 in ap_mpm_run (_pconf=<value optimized out>,
> plog=<value optimized out>, s=<value optimized out>) at
> /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:983
>         index = <value optimized out>
>         remaining_children_to_start = <value optimized out>
>         rv = <value optimized out>
> #12 0x00007ffff7fc2900 in main (argc=4, argv=0x7fffffffe338) at
> /usr/src/debug/httpd-2.2.15/server/main.c:760
>         c = 102 'f'
>         configtestonly = <value optimized out>
>         confname = 0x7fffffffe5c2 "/etc/httpd/conf/httpd.conf"
>         def_server_root = 0x7ffff7fed1f3 "/etc/httpd"
>         temp_error_log = 0x0
>         error = <value optimized out>
>         process = 0x7ffff8212880
>         server_conf = 0x7ffff8212880
>         pglobal = 0x7ffff8209148
>         pconf = 0x7ffff820b158
>         plog = 0x7ffff823d2e8
>         ptemp = 0x7ffff820f178
>         pcommands = 0x7ffff820d168
>         opt = 0x7ffff820d260
>         rv = <value optimized out>
>         mod = <value optimized out>
> ---Type <return> to continue, or q <return> to quit---
>         optarg = 0x7fffffffe5c2 "/etc/httpd/conf/httpd.conf"
>         signal_server = <value optimized out>
>
>
>
>
>
>
>
>
>
> On 13 February 2014 03:25, Felipe Costa <FC...@tr...> wrote:
>
>>  Hi Bruno,
>>
>>  Thank you for the report.
>>
>>  Do you mind to generate more information using GDB?
>>
>>  I've just create a guide on how to use GDB to help in the bug reporting
>> process, it is available under our wiki:
>> https://github.com/SpiderLabs/ModSecurity/wiki/Debugging-ModSecurity
>>
>>  Thanks,
>>  *Felipe "Zimmerle" Costa*
>>  Security Researcher, SpiderLabs
>>
>>  *Trustwave* | SMART SECURITY ON DEMAND
>>  www.trustwave.com
>>
>>    On Feb 12, 2014, at 9:23 AM, Bruno Savioli de Almeida <
>> br...@sa...> wrote:
>>
>>    Hi,
>>
>>  I'm testing the JSON patches from the json_top_of_2_7_7 branch and I'm
>> getting what appears to be random segfaults. I say random because I haven't
>> managed to identify any patterns on the type of requests that segfaults.
>>
>>  Test environment:
>> Centos 6.5 x86_64
>> httpd-2.2.15-29.el6.centos.x86_64
>> mod_security compiled with yajl-2.0.5
>>
>>
>>  I'm running mod_security in DETECTION_ONLY mode, with the owasp crs and
>> JSON requestBodyProcessor enabled
>>
>>  When the request segfaults, the audit log only records parts A and B:
>>
>>  To avoid making this email too long, logs are here:
>> http://pastebin.com/MnehgvJw
>>
>>  Let me know if I can help with any more information.
>>
>>
>>  Thanks,
>>
>>
>>  --
>> - Bruno
>>  ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> 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
>>
>>
>>
>> ------------------------------
>>
>> 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.
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> 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
>>
>
>
>
>  --
> - Bruno
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> 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
>
>
>
> ------------------------------
>
> 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.
>



-- 
- Bruno

[Mod-security-developers] sanitiseArgs not working with JSON payload

[Bruno S. de A. <br...@sa...>]

Hi,

I'm testing 2.8.0 with the JSON request body processor and it seems that
the sanitiseArgs is not working as expected.

It detects the fields, it matches the rule, but it logs the data in the
clear, even though modsec logs which args were sanitised.

Rule:
SecAction
"phase:5,id:'6660666',t:none,pass,nolog,sanitiseArg:cardNumber,sanitiseArg:cardToken"

audit log:
[29/Apr/2014:12:19:54 +0100] U1@K2goFLh4AAHIFMqAAAAAS 10.5.12.18 43609
10.5.46.31 443
--72235b1e-B--
POST /psp/save HTTP/1.1
User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: payments
Content-Type: application/json;charset=UTF-8
Accept: application/json
Content-Length: 114

--72235b1e-C--
{"cardToken":"aaaaaaaaaaaaaaaaaaaaaaaaaa1111111111111111111111aaaaaaaaaaaaaaaaaa","cardNumber":"1000000000000001"}
--72235b1e-F--
HTTP/1.1 400 Bad Request
Content-Type: application/json
Via: 1.1 payments
Content-Length: 78
Connection: close

--72235b1e-E--
{"message":"Please check your input and try again.","error":"Invalid
Details"}
--72235b1e-H--
Apache-Handler: proxy-server
Stopwatch: 1398770394130647 22955 (- - -)
Stopwatch2: 1398770394130647 22955; combined=2733, p1=266, p2=2062, p3=9,
p4=355, p5=40, sr=86, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.8.0 (http://www.modsecurity.org/);
OWASP_CRS/2.2.9.
Server: Apache
Sanitised-Args: "cardNumber", "cardToken".
Engine-Mode: "DETECTION_ONLY"


A Similar request using  application/x-www-form-urlencoded works as
expected.

Thanks,

-- 
- Bruno

[Mod-security-developers] Announcing ModSecurity v2.8.0

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

Hi,

It is a pleasure to announce ModSecurity v2.8.0. Besides the bug fixes and improvements, it comes with five important new features:

  *   JSON request body parser.
  *   SecConnReadStateLimit and SecConnWriteStateLimit directives.
  *   FULL_REQUEST and FULL_REQUEST_LENGTH variables.
  *   @detectXSS operator.
  *   ModSecurity status reporting.
  *   Append and prepend are now supported on nginx (Ref: #635<https://github.com/SpiderLabs/ModSecurity/issues/635>).
  *   SecServerSignature is now available on nginx (Ref: #637<https://github.com/SpiderLabs/ModSecurity/issues/637>).

Complete list of modifications: https://github.com/SpiderLabs/ModSecurity/releases

Further information on the release: http://blog.spiderlabs.com/2014/04/announcing-modsecurity-v280.html

Note: we are also modifying the name of our release tarball. We were labeling our release by: "modsecurity-apache_X.Y.Z.tar.gz", since we started to support Nginx, this name became outdated. Now we are labeling it as  "modsecurity-X.Y.Z.tar.gz". For those who are automagically generating packages, it won't be a problem, the old naming policy will be preserved on the modsecurity.org<http://modsecurity.org/> server.

As in the last release, this release will be stored in two different servers: modsecurity.org<http://modsecurity.org/> and GitHub. Hashes are provided for the tarball integrity verification. The release tags are also GPG-Signed.

Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs
m: +55 81 8706.5547

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>



________________________________

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.

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Derek & V. <the...@gm...>]

Well I got it working for the 2.7.7 version, it turns out that the path 
I used to utsname.h was just a header file that referenced other 
locations.  So I searched for other copies of the utsname.h and made 
sure that they were complete files.  Then it finished compiling.  I 
don't know if the image works yet but I know it builds.  Going to try 
the 2.8.0 RC-1 and if that builds I'll try that image on the openwrt 
powered Pi.
Thanks for your help Felipe.  I'll be sending a note to get advice on 
what CRS rules make the most sense on a forward prox y.
Derek

On 04/11/2014 08:43 AM, Felipe Costa wrote:
> Hi Derek,
>
> You are able to compile a previous version (in a *fresh* directory), 
> lets say version 2.7.7?
>
> I am asking that cause this "nested too deeply" is usually consequence 
> of a circular dependency.
>
> Not sure what is happening, but it seems to be a cross compiling 
> issue, if it was the case, disable the status engine you will not help 
> you.
>
> Can you share your config.log ?
>
> Are you using this:
> http://wiki.openwrt.org/doc/howto/build ?
>
> After run the ./autogen and ./configure there should be a file named: 
> "apache2/modsecurity_config_auto.h" inside this file, there is a 
> definition: HAVE_SYS_UTSNAME_H. Set this definition to "0" and it 
> should act like sys/utsname.h does not exist in your platform.
>
> Br.,
> *Felipe "Zimmerle" Costa*
> Security Researcher, SpiderLabs
>
> *Trustwave* | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>
>
> On Apr 10, 2014, at 11:24 PM, Derek & Vicky <the...@gm... 
> <mailto:the...@gm...>>
>  wrote:
>
>> Is there a configure option to disable the status engine? so its not 
>> built?  My compile process is stuck on that right now and I'd like to 
>> disable it so I can get things working then go back and add things in.
>>
>> Thanks
>>     Derek
>>
>> On 04/09/2014 08:10 AM, Derek Werthmuller wrote:
>>> Felipe,
>>> I Setup a clean build directory and now utsname.sys is found along 
>>> with the signal.h and errno.h.  But now I'm getting this "include 
>>> nested too deeply" message.
>>> Now I added the path to the path to utsname.sys to my makefile by 
>>> using the TARGET_CPPFLAGS, its found in toolchain/include/sys
>>>
>>> TARGET_CPPFLAGS += \
>>>         -I$(STAGING_DIR)/usr/include/libxml2 \
>>>         -I$(STAGING_DIR)/usr/share/build/ \
>>>         -I$(STAGING_DIR)/usr/include/apache \
>>>         -I$(STAGING_DIR)/usr/include/apr-1 \
>>>         -I$(STAGING_DIR)/usr/lib/ \
>>>         -I$(TOOLCHAIN_DIR)/include/sys \
>>>
>>> development/openwrt/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/include/sys/signal.h:1:20: 
>>> error: #include nested too deeply
>>>  #include <signal.h>
>>>                     ^
>>> make[5]: *** [mod_security2_la-acmp.lo] Error 1
>>>
>>> Any ideas how to get past this error, I'm not really sure what it means.
>>>
>>> Thanks
>>>  Derek
>>>
>>> On Fri, Apr 4, 2014 at 12:56 PM, Felipe Costa <FC...@tr... 
>>> <mailto:FC...@tr...>> wrote:
>>>
>>>     Hi Derek,
>>>
>>>     On Apr 4, 2014, at 1:33 PM, Derek Werthmuller
>>>     <the...@gm... <mailto:the...@gm...>>
>>>      wrote:
>>>
>>>>     Felipe,
>>>>     That utsname_autotools gave me the "msc_status_engine.c:137:26:
>>>>     error: storage size of 'u' isn't known
>>>>     make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
>>>>     "
>>>>     Error again.
>>>
>>>     Thanks for test.
>>>
>>>     Can you double check if you are really on the
>>>     "utsname_autotools" branch? Can you try it in a fresh directory?
>>>
>>>     It seems to me that this error is part of "master", as this line
>>>     137 is where this structure is used at the branch master.
>>>     In utsname_autotools, if happens, it should be on line 140 (if i
>>>     am not mistaken).
>>>
>>>     Can you double check that? Also, can you check if there is
>>>     something similar to "#define HAVE_SYS_UTSNAME_H 1" in your
>>>     config.log ?
>>>
>>>
>>>>     Should I try the other fix version you setup?
>>>     Lets have this second chance on the branch: "msc_status_engine"
>>>     first. I want to push this to master, but first i want to make
>>>     sure that it is working for everybody.
>>>
>>>     Thanks for helping us to sort this out ;)
>>>
>>>
>>>     Br.,
>>>     *Felipe "Zimmerle" Costa*
>>>     Security Researcher, SpiderLabs
>>>
>>>     *Trustwave* | SMART SECURITY ON DEMAND
>>>     www.trustwave.com <http://www.trustwave.com/>
>>>
>>>
>>>
>>>     ------------------------------------------------------------------------
>>>
>>>     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 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
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Put Bad Developers to Shame
>> Dominate Development with Jenkins Continuous Integration
>> Continuously Automate Build, Test & Deployment
>> Start a new project now. Try Jenkins in the cloud.
>> http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------
>
> 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.
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
> _______________________________________________
> 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] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

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

Hi Derek,

You are able to compile a previous version (in a *fresh* directory), lets say version 2.7.7?

I am asking that cause this "nested too deeply" is usually consequence of a circular dependency.

Not sure what is happening, but it seems to be a cross compiling issue, if it was the case, disable the status engine you will not help you.

Can you share your config.log ?

Are you using this:
http://wiki.openwrt.org/doc/howto/build ?

After run the ./autogen and ./configure there should be a file named: "apache2/modsecurity_config_auto.h" inside this file, there is a definition: HAVE_SYS_UTSNAME_H. Set this definition to "0" and it should act like sys/utsname.h does not exist in your platform.

Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>


On Apr 10, 2014, at 11:24 PM, Derek & Vicky <the...@gm...<mailto:the...@gm...>>
 wrote:

Is there a configure option to disable the status engine? so its not built?  My compile process is stuck on that right now and I'd like to disable it so I can get things working then go back and add things in.

Thanks
    Derek

On 04/09/2014 08:10 AM, Derek Werthmuller wrote:
Felipe,
I Setup a clean build directory and now utsname.sys is found along with the signal.h and errno.h.  But now I'm getting this "include nested too deeply" message.
Now I added the path to the path to utsname.sys to my makefile by using the TARGET_CPPFLAGS, its found in toolchain/include/sys

TARGET_CPPFLAGS += \
        -I$(STAGING_DIR)/usr/include/libxml2 \
        -I$(STAGING_DIR)/usr/share/build/ \
        -I$(STAGING_DIR)/usr/include/apache \
        -I$(STAGING_DIR)/usr/include/apr-1 \
        -I$(STAGING_DIR)/usr/lib/ \
        -I$(TOOLCHAIN_DIR)/include/sys \

development/openwrt/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/include/sys/signal.h:1:20: error: #include nested too deeply
 #include <signal.h>
                    ^
make[5]: *** [mod_security2_la-acmp.lo] Error 1

Any ideas how to get past this error, I'm not really sure what it means.

Thanks
 Derek

On Fri, Apr 4, 2014 at 12:56 PM, Felipe Costa <FC...@tr...<mailto:FC...@tr...>> wrote:
Hi Derek,

On Apr 4, 2014, at 1:33 PM, Derek Werthmuller <the...@gm...<mailto:the...@gm...>>
 wrote:

Felipe,
That utsname_autotools gave me the "msc_status_engine.c:137:26: error: storage size of 'u' isn't known
make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
"
Error again.

Thanks for test.

Can you double check if you are really on the "utsname_autotools" branch? Can you try it in a fresh directory?

It seems to me that this error is part of "master", as this line 137 is where this structure is used at the branch master. In utsname_autotools, if happens, it should be on line 140 (if i am not mistaken).

Can you double check that? Also, can you check if there is something similar to "#define HAVE_SYS_UTSNAME_H 1" in your config.log ?


Should I try the other fix version you setup?
Lets have this second chance on the branch: "msc_status_engine" first. I want to push this to master, but first i want to make sure that it is working for everybody.

Thanks for helping us to sort this out ;)


Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>



________________________________

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 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


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_______________________________________________
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


________________________________

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.

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Derek & V. <the...@gm...>]

Is there a configure option to disable the status engine? so its not 
built?  My compile process is stuck on that right now and I'd like to 
disable it so I can get things working then go back and add things in.

Thanks
     Derek

On 04/09/2014 08:10 AM, Derek Werthmuller wrote:
> Felipe,
> I Setup a clean build directory and now utsname.sys is found along 
> with the signal.h and errno.h.  But now I'm getting this "include 
> nested too deeply" message.
> Now I added the path to the path to utsname.sys to my makefile by 
> using the TARGET_CPPFLAGS, its found in toolchain/include/sys
>
> TARGET_CPPFLAGS += \
>         -I$(STAGING_DIR)/usr/include/libxml2 \
>         -I$(STAGING_DIR)/usr/share/build/ \
>         -I$(STAGING_DIR)/usr/include/apache \
>         -I$(STAGING_DIR)/usr/include/apr-1 \
>         -I$(STAGING_DIR)/usr/lib/ \
>         -I$(TOOLCHAIN_DIR)/include/sys \
>
> development/openwrt/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/include/sys/signal.h:1:20: 
> error: #include nested too deeply
>  #include <signal.h>
>                     ^
> make[5]: *** [mod_security2_la-acmp.lo] Error 1
>
> Any ideas how to get past this error, I'm not really sure what it means.
>
> Thanks
>  Derek
>
> On Fri, Apr 4, 2014 at 12:56 PM, Felipe Costa <FC...@tr... 
> <mailto:FC...@tr...>> wrote:
>
>     Hi Derek,
>
>     On Apr 4, 2014, at 1:33 PM, Derek Werthmuller
>     <the...@gm... <mailto:the...@gm...>>
>      wrote:
>
>>     Felipe,
>>     That utsname_autotools gave me the "msc_status_engine.c:137:26:
>>     error: storage size of 'u' isn't known
>>     make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
>>     "
>>     Error again.
>
>     Thanks for test.
>
>     Can you double check if you are really on the "utsname_autotools"
>     branch? Can you try it in a fresh directory?
>
>     It seems to me that this error is part of "master", as this line
>     137 is where this structure is used at the branch master.
>     In utsname_autotools, if happens, it should be on line 140 (if i
>     am not mistaken).
>
>     Can you double check that? Also, can you check if there is
>     something similar to "#define HAVE_SYS_UTSNAME_H 1" in your
>     config.log ?
>
>
>>     Should I try the other fix version you setup?
>     Lets have this second chance on the branch: "msc_status_engine"
>     first. I want to push this to master, but first i want to make
>     sure that it is working for everybody.
>
>     Thanks for helping us to sort this out ;)
>
>
>     Br.,
>     *Felipe "Zimmerle" Costa*
>     Security Researcher, SpiderLabs
>
>     *Trustwave* | SMART SECURITY ON DEMAND
>     www.trustwave.com <http://www.trustwave.com/>
>
>
>
>     ------------------------------------------------------------------------
>
>     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 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
>
>

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Derek W. <the...@gm...>]

Felipe,
I Setup a clean build directory and now utsname.sys is found along with the
signal.h and errno.h.  But now I'm getting this "include nested too deeply"
message.
Now I added the path to the path to utsname.sys to my makefile by using the
TARGET_CPPFLAGS, its found in toolchain/include/sys

TARGET_CPPFLAGS += \
        -I$(STAGING_DIR)/usr/include/libxml2 \
        -I$(STAGING_DIR)/usr/share/build/ \
        -I$(STAGING_DIR)/usr/include/apache \
        -I$(STAGING_DIR)/usr/include/apr-1 \
        -I$(STAGING_DIR)/usr/lib/ \
        -I$(TOOLCHAIN_DIR)/include/sys \

development/openwrt/staging_dir/toolchain-arm_arm1176jzf-s+vfp_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/include/sys/signal.h:1:20:
error: #include nested too deeply
 #include <signal.h>
                    ^
make[5]: *** [mod_security2_la-acmp.lo] Error 1

Any ideas how to get past this error, I'm not really sure what it means.

Thanks
 Derek

On Fri, Apr 4, 2014 at 12:56 PM, Felipe Costa <FC...@tr...> wrote:

>  Hi Derek,
>
>  On Apr 4, 2014, at 1:33 PM, Derek Werthmuller <the...@gm...>
>   wrote:
>
>   Felipe,
>  That utsname_autotools gave me the "msc_status_engine.c:137:26: error:
> storage size of 'u' isn't known
> make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
> "
>  Error again.
>
>
>  Thanks for test.
>
>  Can you double check if you are really on the "utsname_autotools"
> branch? Can you try it in a fresh directory?
>
>  It seems to me that this error is part of "master", as this line 137 is
> where this structure is used at the branch master. In utsname_autotools, if
> happens, it should be on line 140 (if i am not mistaken).
>
>  Can you double check that? Also, can you check if there is something
> similar to "#define HAVE_SYS_UTSNAME_H 1" in your config.log ?
>
>
>  Should I try the other fix version you setup?
>
> Lets have this second chance on the branch: "msc_status_engine" first. I
> want to push this to master, but first i want to make sure that it is
> working for everybody.
>
>  Thanks for helping us to sort this out ;)
>
>
>  Br.,
>   *Felipe "Zimmerle" Costa*
>  Security Researcher, SpiderLabs
>
>  *Trustwave* | SMART SECURITY ON DEMAND
>  www.trustwave.com
>
>
>
> ------------------------------
>
> 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 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] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

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

Hi Derek,

On Apr 4, 2014, at 1:33 PM, Derek Werthmuller <the...@gm...<mailto:the...@gm...>>
 wrote:

Felipe,
That utsname_autotools gave me the "msc_status_engine.c:137:26: error: storage size of 'u' isn't known
make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
"
Error again.

Thanks for test.

Can you double check if you are really on the "utsname_autotools" branch? Can you try it in a fresh directory?

It seems to me that this error is part of "master", as this line 137 is where this structure is used at the branch master. In utsname_autotools, if happens, it should be on line 140 (if i am not mistaken).

Can you double check that? Also, can you check if there is something similar to "#define HAVE_SYS_UTSNAME_H 1" in your config.log ?


Should I try the other fix version you setup?
Lets have this second chance on the branch: "msc_status_engine" first. I want to push this to master, but first i want to make sure that it is working for everybody.

Thanks for helping us to sort this out ;)


Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>



________________________________

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.

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Derek W. <the...@gm...>]

Felipe,
That utsname_autotools gave me the "msc_status_engine.c:137:26: error:
storage size of 'u' isn't known
make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
"
Error again.
Should I try the other fix version you setup?


On Thu, Apr 3, 2014 at 8:52 AM, Felipe Costa <FC...@tr...> wrote:

>
>  Hi,
>
>  On Apr 3, 2014, at 9:31 AM, Derek & Vicky <the...@gm...>
>   wrote:
>
>  Felipe,
> Using the cross test code I no longer get that error message. I get others
> but those may be related to my cross compile build environment.
> Cheers
>     Derek
>
>
>  Cool :)
>
>  Can you give a try on:
> https://github.com/SpiderLabs/ModSecurity/tree/utsname_autotools
>
>  I think this last one is a more appropriate fix.
>
>  Regarding to the other problems that you are facing while
> cross-compiling, if you want to share... not sure if I can help, but I can
> try.
>
>
>  Br.,
>  *Felipe "Zimmerle" Costa*
>  Security Researcher, SpiderLabs
>
>  *Trustwave* | SMART SECURITY ON DEMAND
>  www.trustwave.com
>
>
>
> ------------------------------
>
> 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 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] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

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

Hi,

On Apr 3, 2014, at 9:31 AM, Derek & Vicky <the...@gm...<mailto:the...@gm...>>
 wrote:

Felipe,
Using the cross test code I no longer get that error message. I get others but those may be related to my cross compile build environment.
Cheers
    Derek

Cool :)

Can you give a try on:
https://github.com/SpiderLabs/ModSecurity/tree/utsname_autotools

I think this last one is a more appropriate fix.

Regarding to the other problems that you are facing while cross-compiling, if you want to share... not sure if I can help, but I can try.


Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>



________________________________

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.

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Derek & V. <the...@gm...>]

Felipe,
Using the cross test code I no longer get that error message. I get 
others but those may be related to my cross compile build environment.
Cheers
     Derek

On 04/02/2014 09:25 AM, Felipe Costa wrote:
> Hi Derek,
>
> The problem probably happens due to the lack of the inclusion of this 
> header: sys/utsname.h
>
> This header is just used on Linux, so prior to the inclusion I am 
> doing a verification to see if the target machine is a Linux or not, 
> for that, I was using the following condition:
> #ifdef __gnu_linux__
> ...
> #endif
>
> Probably your cross compiler was not setting this macro. I have 
> changed it to:
> #if (defined(__linux__) || defined(__gnu_linux__))
> ...
> #endif
>
> This sound more `fail proof`. The modification is available at the 
> branch: cross_test
>
> https://github.com/SpiderLabs/ModSecurity/tree/cross_test
>
> Can you check if it is working fine?
>
> If not, can you send me the list of pre-defined macros of your 
> compiler? Easy to get the list:
>
> touch /tmp/somefile.c
> cpp -dM /tmp/somefile.c
>
> Change cpp for your C++ cross compiler alternative.
>
> Br.,
> *Felipe "Zimmerle" Costa*
> Security Researcher, SpiderLabs
>
> *Trustwave* | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
>
>
>
> On Apr 2, 2014, at 9:32 AM, Derek Werthmuller <the...@gm... 
> <mailto:the...@gm...>>
>  wrote:
>
>> I've given up on nginx and modsecurity.  Not because I don't think it 
>> works but because nginx is not a good forward proxy.  I'm now working 
>> to get the cross compile to work for the modsecurity and apache.
>>
>> I'm using the latest rc 2.8.0   and am getting a compile error, not 
>> sure if its due to tool chain issues or an issue with the code.   
>> I've downloaded the code from git. 
>> https://github.com/SpiderLabs/ModSecurity/releases/download/v2.8.0-rc1/
>>
>> msc_status_engine.c: In function 'msc_status_engine_machine_name':
>> msc_status_engine.c:137:26: error: storage size of 'u' isn't known
>>     static struct utsname u;
>>                           ^
>> make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1
>>
>> Thanks
>>   Derek
>>
>>
>> On Sat, Feb 22, 2014 at 8:51 PM, Derek Werthmuller 
>> <the...@gm... <mailto:the...@gm...>> wrote:
>>
>>     Working on setting modsecurity with nginx in a forward proxy
>>     configuration on a raspberry pi.
>>     I've got modsecurity building ok it seems. Have nginx building
>>     with out modsecurity ok.  But nginx will not link properly with
>>     modsecurity.
>>
>>     nginx 1.5.10
>>     apache 2.2.26
>>     modsecurity 2.7.7
>>
>>     Getting lots of messages like
>>     modsecurity-apache_2.7.7/nginx/modsecurity/apr_bucket_nginx.c:67:
>>     undefined reference to `apr_bucket_free'
>>
>>     nginx doesn't have a with-apr section in its configure script, so
>>     I figure this is referring to modsecurity's use of apr.
>>
>>     Also seems to be having trouble finding the libxml2 libraries.
>>     Bunch of these messages too.
>>     ../modsecurity-apache_2.7.7/nginx/modsecurity/../../standalone/.libs/standalone.a(standalone_la-msc_crypt.o):
>>     In function `hash_response_body_links':
>>     msc_crypt.c:(.text+0x17ec): undefined reference to
>>     `xmlXPathNewContext'
>>     msc_crypt.c:(.text+0x184c): undefined reference to
>>     `xmlXPathEvalExpression'
>>
>>     Any guidance on getting this compiled correctly?
>>     Cheers
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------
>
> 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 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] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

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

Hey,

On Apr 2, 2014, at 6:00 PM, Walter Hop <mo...@sp...<mailto:mo...@sp...>> wrote:

Awesome! Looking good. It builds, installs, passes unit tests and passes our own regression tests on FreeBSD 9.2 amd64 + Apache.

I haven’t had time to check the new features yet, I will look at those probably Monday.

Nice to hear that :)

FreeBSD is on the list to be part of our Build farms, as you can see here:

http://www.modsecurity.org/developers/buildbot/builders/FreeBSD%20-%20Apache

We don't have the virtual machine ready yet. I will work on that for the next release.

Thanks for you help testing and reporting,


Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>


________________________________

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.

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Walter H. <mo...@sp...>]

On 02 Apr 2014, at 21:03, Felipe Costa <FC...@tr...> wrote:

> Instead of have hardcoded #ifdefs, I am now checking for this header using autotools, during the configure.
> 
> Here goes the new branch: 
> https://github.com/SpiderLabs/ModSecurity/tree/utsname_autotools
> 
> Can you guys check if it is working fine?

Awesome! Looking good. It builds, installs, passes unit tests and passes our own regression tests on FreeBSD 9.2 amd64 + Apache.

I haven’t had time to check the new features yet, I will look at those probably Monday.

Kind regards,
WH

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

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

Hi Walter,

It seems that a lot of platforms does have this header file and structure:

Solaris: http://docs.oracle.com/cd/E23823_01/html/816-5167/uname-2.html#REFMAN2uname-2
AIX: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf2/uname.htm
NetWere: http://www.novell.com/documentation/developer/libc/libc_vol2/data/aioskrg.html
MacOS: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/uname.3.html
HPUX: http://www.hpmigrations.com/hpe3000_resources/MPE_to_HP-UX_cross-reference/system_administration_cross-reference/cmd.html?cmdid=MS_303
FreeBSD: http://www.freebsd.org/cgi/man.cgi?query=uname&sektion=3&n=1
OpenBSD: http://nixdoc.net/man-pages/OpenBSD/uname.3.html
NetBSD: http://netbsd.gw.com/cgi-bin/man-cgi?uname+3+NetBSD-6.0.1
Linux: http://linux.die.net/man/2/uname

Instead of have hardcoded #ifdefs, I am now checking for this header using autotools, during the configure.

Here goes the new branch:
https://github.com/SpiderLabs/ModSecurity/tree/utsname_autotools

Can you guys check if it is working fine?

Thanks,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>





On Apr 2, 2014, at 12:49 PM, Walter Hop <mo...@sp...<mailto:mo...@sp...>> wrote:

Hi Felipe,

I have a similar compiler error when building on FreeBSD. The error remains after applying the patch. For completeness:

msc_status_engine.c: In function 'msc_status_engine_machine_name':
msc_status_engine.c:137: error: storage size of 'u' isn't known
*** [mod_security2_la-msc_status_engine.lo] Error code 1

FreeBSD does have utsname.h. You can find the man page here:
http://www.freebsd.org/cgi/man.cgi?query=uname&sektion=3&n=1

If necessary, my macros are at: http://lf.ms/macros.txt
Glad to help so let us know if we should retry.

Kind regards,
WH

On 02 Apr 2014, at 15:25, Felipe Costa <FC...@tr...<mailto:FC...@tr...>> wrote:

Probably your cross compiler was not setting this macro. I have changed it to:
#if (defined(__linux__) || defined(__gnu_linux__))
…
#endif

This sound more `fail proof`. The modification is available at the branch: cross_test

https://github.com/SpiderLabs/ModSecurity/tree/cross_test

Can you check if it is working fine?

If not, can you send me the list of pre-defined macros of your compiler? Easy to get the list:

touch /tmp/somefile.c
cpp -dM /tmp/somefile.c

--
Walter Hop | wa...@li...<mailto:wa...@li...> | PGP key: https://lifeforms.nl/pgp

------------------------------------------------------------------------------
_______________________________________________
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


________________________________

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.

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

[Walter H. <mo...@sp...>]

Hi Felipe,

I have a similar compiler error when building on FreeBSD. The error remains after applying the patch. For completeness:

msc_status_engine.c: In function 'msc_status_engine_machine_name':
msc_status_engine.c:137: error: storage size of 'u' isn't known
*** [mod_security2_la-msc_status_engine.lo] Error code 1

FreeBSD does have utsname.h. You can find the man page here:
http://www.freebsd.org/cgi/man.cgi?query=uname&sektion=3&n=1

If necessary, my macros are at: http://lf.ms/macros.txt
Glad to help so let us know if we should retry.

Kind regards,
WH

On 02 Apr 2014, at 15:25, Felipe Costa <FC...@tr...> wrote:

> Probably your cross compiler was not setting this macro. I have changed it to:
> #if (defined(__linux__) || defined(__gnu_linux__))
> …
> #endif
> 
> This sound more `fail proof`. The modification is available at the branch: cross_test
> 
> https://github.com/SpiderLabs/ModSecurity/tree/cross_test
> 
> Can you check if it is working fine?
> 
> If not, can you send me the list of pre-defined macros of your compiler? Easy to get the list:
> 
> touch /tmp/somefile.c
> cpp -dM /tmp/somefile.c

-- 
Walter Hop | wa...@li... | PGP key: https://lifeforms.nl/pgp

Re: [Mod-security-developers] cross compiling modsecurity for nginx on openwrt for raspberry pi platform

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

Hi Derek,

The problem probably happens due to the lack of the inclusion of this header: sys/utsname.h

This header is just used on Linux, so prior to the inclusion I am doing a verification to see if the target machine is a Linux or not, for that, I was using the following condition:
#ifdef __gnu_linux__
…
#endif

Probably your cross compiler was not setting this macro. I have changed it to:
#if (defined(__linux__) || defined(__gnu_linux__))
…
#endif

This sound more `fail proof`. The modification is available at the branch: cross_test

https://github.com/SpiderLabs/ModSecurity/tree/cross_test

Can you check if it is working fine?

If not, can you send me the list of pre-defined macros of your compiler? Easy to get the list:

touch /tmp/somefile.c
cpp -dM /tmp/somefile.c

Change cpp for your C++ cross compiler alternative.

Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>



On Apr 2, 2014, at 9:32 AM, Derek Werthmuller <the...@gm...<mailto:the...@gm...>>
 wrote:

I've given up on nginx and modsecurity.  Not because I don't think it works but because nginx is not a good forward proxy.  I'm now working to get the cross compile to work for the modsecurity and apache.

I'm using the latest rc 2.8.0   and am getting a compile error, not sure if its due to tool chain issues or an issue with the code.   I've downloaded the code from git.  https://github.com/SpiderLabs/ModSecurity/releases/download/v2.8.0-rc1/

msc_status_engine.c: In function 'msc_status_engine_machine_name':
msc_status_engine.c:137:26: error: storage size of 'u' isn't known
    static struct utsname u;
                          ^
make[5]: *** [mod_security2_la-msc_status_engine.lo] Error 1

Thanks
  Derek


On Sat, Feb 22, 2014 at 8:51 PM, Derek Werthmuller <the...@gm...<mailto:the...@gm...>> wrote:
Working on setting modsecurity with nginx in a forward proxy configuration on a raspberry pi.
I've got modsecurity building ok it seems. Have nginx building with out modsecurity ok.  But nginx will not link properly with modsecurity.

nginx 1.5.10
apache 2.2.26
modsecurity 2.7.7

Getting lots of messages like modsecurity-apache_2.7.7/nginx/modsecurity/apr_bucket_nginx.c:67: undefined reference to `apr_bucket_free'

nginx doesn't have a with-apr section in its configure script, so I figure this is referring to modsecurity's use of apr.

Also seems to be having trouble finding the libxml2 libraries.
Bunch of these messages too.
../modsecurity-apache_2.7.7/nginx/modsecurity/../../standalone/.libs/standalone.a(standalone_la-msc_crypt.o): In function `hash_response_body_links':
msc_crypt.c:(.text+0x17ec): undefined reference to `xmlXPathNewContext'
msc_crypt.c:(.text+0x184c): undefined reference to `xmlXPathEvalExpression'

Any guidance on getting this compiled correctly?
Cheers


------------------------------------------------------------------------------
_______________________________________________
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


________________________________

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.