Re: [Mod-security-developers] mod-security-developers Digest, Vol 53, Issue 1

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

As autoconf conventions,  it seems that "--with-curl=no"  should be "without-curl" ? 

Filex: ta...@le...

> -----Original Message-----
> From: mod...@li... [mailto:mod-
> sec...@li...]
> Sent: Tuesday, January 05, 2016 1:10
> To: mod...@li...
> Subject: mod-security-developers Digest, Vol 53, Issue 1
> 
> Send mod-security-developers mailing list submissions to
> 	mod...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> or, via email, send a message with subject or body 'help' to
> 	mod...@li...
> 
> You can reach the person managing the list at
> 	mod...@li...
> 
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of mod-security-developers digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Antwort: Re: compile modsecurity --with-curl=no (Felipe Costa)
>    2. Re: [mod-security-users] Problems with @inspectFile not
>       escaping arguments (Felipe Costa)
>    3. More about ModSecurity version 3 (Felipe Costa)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 16 Nov 2015 18:39:32 +0000
> From: Felipe Costa <FC...@tr...>
> Subject: Re: [Mod-security-developers] Antwort: Re: compile
> 	modsecurity --with-curl=no
> To: "mod...@li..."
> 	<mod...@li...>
> Message-ID: <D26FA827.16A6A%fc...@tr...>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Christian,
> 
> It is natural that you cannot build the mlogc without the curl dependency, as it is
> a mandatory dependency.
> 
> I will try to investigate the semaphore issue. Meanwhile, you may want to
> manually cleanup the semaphores. Here is what we use on our buildbots:
> https://gist.github.com/zimmerle/f4fd10f9b0485abb4872
> 
> 
> Br.,
> Felipe ?Zimmerle? Costa
> Security Researcher, SpiderLabs
> 
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
> 
> 
> 
> 
> 
> From:  "chr...@go..."
> <chr...@go...>
> Reply-To:  "mod...@li..."
> <mod...@li...>
> Date:  Monday, November 16, 2015 at 11:21 AM
> To:  "mod...@li..."
> <mod...@li...>
> Subject:  [Mod-security-developers] Antwort: Re: compile
> modsecurity     --with-curl=no
> 
> 
> Hi Felipe,
> 
> my question is related to the semaphore issue:
> https://sourceforge.net/p/mod-security/mailman/message/34613832/
> <http://scanmail.trustwave.com/?c=4062&d=uOfJ1hIm5YUCSUxW9Ytptg5Hx0t
> Kkdky-0
> YSeK_kkw&s=5&u=https%3a%2f%2fsourceforge%2enet%2fp%2fmod-
> security%2fmailman
> %2fmessage%2f34613832%2f>
> 
> No, I didn't manage to compile mlogc using "--with-curl=no". The mlogc binary
> will simply not be build.
> Anyway, building mlogc without curl is no longer important to me. The basic
> problem is the semphore issue.
> 
> I would be very grateful, if the semaphore problem could be addressed.
> It's seems like many others have the same issue.
> Maybe you get some idea how to figure out the problem, if you read my post
> about the semaphore issue.
> 
> Best regards,
> Christian
> 
> 
> 
> 
> Von:        Felipe Costa <FC...@tr...>
> An:        "mod...@li..."
> <mod...@li...>
> Datum:        13.11.2015 22:40
> Betreff:        Re: [Mod-security-developers] compile modsecurity
> --with-curl=no
> ________________________________________
> 
> 
> 
> Hi Christian,
> 
> Mlogc depends on curl to submit the logs to the target host. Did you managed
> to compile the mlogc while using --with-curl=no ?
> 
> Br.,
> Felipe ?Zimmerle? Costa
> 
> Security Researcher, SpiderLabs
> 
> Trustwave| SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
> 
> From: "chr...@go..."
> <chr...@go...>
> Reply-To: "mod...@li..."
> <mod...@li...>
> Date: Monday, November 2, 2015 at 8:34 AM
> To: "mod...@li..."
> <mod...@li...>
> Subject: [Mod-security-developers] compile modsecurity --with-curl=no
> 
> Dear devolopers,
> 
> I searched the mailing lists and google for my question, but didn't find anything.
> Hopefully this is the right place to ask my question.
> 
> 
> We use a modified apache httpd (2.2.29) with modsecurity 2.9.0 on RHEL 6.6
> (64bit). On graceful restarts of the httpd the number semaphore arrays start to
> increase till they reach the limit of 128 when mlogc is enabled.
> The support of the modified httpd suggested  to compile modsecurity "--with-
> curl=no". The number of semaphore arrays is not encreasing anymore.
> 
> Now my question is which impact will this option have on modsecurity/mlogc?
> 
> Thanks in advance,
> Christian
> _________________________________________________________________
> __________
> _________________________
> Gesellschaft: Gothaer Systems GmbH
> Sitz: Gothaer Allee 1, 50969 K?ln (Hausanschrift)
> Aufsichtsrat: Dr. Mathias B?hring-Uhle (Vorsitzender)
> Gesch?ftsf?hrung: Dr. Hans Volkmar Weckesser (Vorsitzender), Hans Berg
> Rechtsform: Gesellschaft mit beschr?nkter Haftung
> Registergericht: Amtsgericht K?ln, HRB 25642 USt.-IdNr. DE811850000
> 
> 
> ________________________________________
> 
> 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
> <http://scanmail.trustwave.com/?c=4062&d=uefJ1iK4wZfAPkX8TQkCvTNjrOelk
> AkMds
> B7bRZKBA&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2flistin
> fo%2
> fmod-security-developers>
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php
> 
> 
> _________________________________________________________________
> __________
> _________________________
> Gesellschaft: Gothaer Systems GmbH
> Sitz: Gothaer Allee 1, 50969 K?ln (Hausanschrift)
> Aufsichtsrat: Dr. Mathias B?hring-Uhle (Vorsitzender)
> Gesch?ftsf?hrung: Dr. Hans Volkmar Weckesser (Vorsitzender), Hans Berg
> Rechtsform: Gesellschaft mit beschr?nkter Haftung
> Registergericht: Amtsgericht K?ln, HRB 25642 USt.-IdNr. DE811850000
> 
> 
> ________________________________
> 
> 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.
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 8 Dec 2015 13:04:11 +0000
> From: Felipe Costa <FC...@tr...>
> Subject: Re: [Mod-security-developers] [mod-security-users] Problems
> 	with @inspectFile not escaping arguments
> To: "mod...@li..."
> 	<mod...@li...>
> Cc: "mod...@li..."
> 	<mod...@li...>
> Message-ID: <61F...@tr...>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Gryzli,
> 
> Thank you for the report.
> 
> Do not use the @inspectFile with variables that you don?t have control.
> @inspectFile was originally created to be used with the FILES_TMPNAMES [1] as
> cited on the
> example: [2]. The content of FILES_TMPNAMES is generated by ModSecurity,
> therefore we don?t need to escape.
> 
> I think you concern is more than valid. I am adding a note at the Reference
> manual, so that, others users will not use it in this fashion.
> 
> Maybe what you are looking for is to use the Lua engine [3]. Using the Lua
> engine, you will be able to fetch the variables using: m.getvar("FULL_REQUEST");
> 
> Notice that using FULL_REQUEST is not always a good practice because it may
> drop the performance of your server a little bit.
> 
> 
> For ModSecurity version 3, the @inspectFile may not be necessary anymore. We
> wish to support natively:
>  - Ruby
>  - Python
>  - Lua
>  - Any other suggestion?
> 
> 
> (Moving this discussion to mod...@li...)
> 
> 
> [1] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-
> Manual#files_tmpnames
> [2] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-
> Manual#inspectfile
> [3] https://github.com/SpiderLabs/ModSecurity/wiki/Reference-
> Manual#secrulescript
> 
> 
> 
> Br.,
> Felipe ?Zimmerle? Costa
> Security Researcher, SpiderLabs
> 
> Trustwave | SMART SECURITY ON DEMAND
> www.trustwave.com <http://www.trustwave.com/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 12/8/15, 4:50 AM, "Gryzli Bugbear" <gry...@gm...> wrote:
> 
> >Hi all,
> >
> >I'm trying to make some rules work, and see some very strange behaviour.
> >
> >I have the following rule in mod_security:
> >---
> >SecRule FULL_REQUEST "@inspectFile /tmp/test_script.pl" "id:159, deny,
> >status:406, phase:2"
> >---
> >
> >When I pass some request to Apache I get bunch of logs in error_log
> >looking like this:
> >=========
> >/bin/sh: line 2: Host:: command not found
> >/bin/sh: line 3: Connection:: command not found
> >/bin/sh: line 4: Accept:: command not found
> >/bin/sh: line 5: Upgrade-Insecure-Requests:: command not found
> >/bin/sh: -c: line 6: syntax error near unexpected token `('
> >/bin/sh: -c: line 6: `User-Agent: Mozilla/5.0 (X11; Linux x86_64)
> >AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36'
> >/bin/sh: line 2: Host:: command not found
> >/bin/sh: line 3: Connection:: command not found
> >/bin/sh: line 4: Accept:: command not found
> >/bin/sh: line 5: Upgrade-Insecure-Requests:: command not found
> >/bin/sh: -c: line 6: syntax error near unexpected token `('
> >/bin/sh: -c: line 6: `User-Agent: Mozilla/5.0 (X11; Linux x86_64)
> >AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36'
> >===========
> >
> >It seems that ModSecurity is unable to correctly escape the arguments,
> >which must be sent to the /tmp/test_scrip.pl, which results to
> >execution tries in /bin/sh.
> >
> >This behavior looks extremely dangerous, cause attacker could easily
> >use it to execute malicious code with Apache user.
> >
> >Is this a bug, or there is an option to make ModSecuriy escape
> >correctly the arguments passed ?
> >
> >Regards,
> >Gryzli
> >
> >-----------------------------------------------------------------------
> >------- Go from Idea to Many App Stores Faster with Intel(R) XDK Give
> >your users amazing mobile app experiences with Intel(R) XDK.
> >Use one codebase in this all-in-one HTML5 development environment.
> >Design, debug & build mobile apps & 2D/3D high-impact games for multiple
> OSs.
> >http://scanmail.trustwave.com/?c=4062&d=sozm1oGKqts4aZ2DnwV7U8LosM
> 7zRZ1
> >IEmGX6zHnvw&s=5&u=http%3a%2f%2fpubads%2eg%2edoubleclick%2enet%2f
> gampad%
> >2fclk%3fid%3d254741911%26iu%3d%2f4140
> >_______________________________________________
> >mod-security-users mailing list
> >mod...@li...
> >http://scanmail.trustwave.com/?c=4062&d=sozm1oGKqts4aZ2DnwV7U8LosM
> 7zRZ1
> >IEjaR7DO06Q&s=5&u=https%3a%2f%2flists%2esourceforge%2enet%2flists%2f
> lis
> >tinfo%2fmod-security-users Commercial ModSecurity Rules and Support
> >from Trustwave's SpiderLabs:
> >http://scanmail.trustwave.com/?c=4062&d=sozm1oGKqts4aZ2DnwV7U8LosM
> 7zRZ1
> >IEmTDuGrg7Q&s=5&u=http%3a%2f%2fwww%2emodsecurity%2eorg%2fprojec
> ts%2fcom
> >mercial%2frules%2f
> >http://scanmail.trustwave.com/?c=4062&d=sozm1oGKqts4aZ2DnwV7U8LosM
> 7zRZ1
> >IEmXH6ma0uA&s=5&u=http%3a%2f%2fwww%2emodsecurity%2eorg%2fproje
> cts%2fcom
> >mercial%2fsupport%2f
> 
> ________________________________
> 
> 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.
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 4 Jan 2016 17:09:54 +0000
> From: Felipe Costa <FC...@tr...>
> Subject: [Mod-security-developers] More about ModSecurity version 3
> To: "mod...@li..."
> 	<mod...@li...>
> Cc: "mod...@li..."
> 	<mod...@li...>
> Message-ID: <2EF...@tr...>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Guys,
> 
> Not sure if you had the opportunity to saw, recently I made two blog posts
> about the libModSecurity, available here:
> 
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> 
> 
> ------------------------------
> 
> _______________________________________________
> mod-security-developers mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> 
> 
> End of mod-security-developers Digest, Vol 53, Issue 1
> ******************************************************