Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 180150 - net-www/mod_security-2.1.1 in conjunction with mod_limitipconn will allow blocked requests through
Summary: net-www/mod_security-2.1.1 in conjunction with mod_limitipconn will allow blo...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Luca Longinotti (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 189995
  Show dependency tree
 
Reported: 2007-05-28 21:06 UTC by lou
Modified: 2007-09-08 08:10 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild for portage overlay that includes the patch (mod_security-2.1.1.ebuild,1.54 KB, text/plain)
2007-05-31 21:51 UTC, lou
Details
patch created by mod_security team to address mod_limitipconn module issue (subrequests.diff,695 bytes, patch)
2007-05-31 21:53 UTC, lou
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description lou 2007-05-28 21:06:11 UTC
Updating to mod_security-2.1.1 from mod_security-1.8.4 AND having mod_limitipconn-0.22-r1 installed will allow triggered blocked requests to still be processed vs blocked.

For example. I have a simple PHP mailer script (process.php). If I fill out the contact form (contact.php) with spam words, and I use the following Mod_sec rule:

SecRule REQUEST_BODY "(spam|content|removed|for|list)" "log,auditlog,deny,phase:2,status:403"

My request should be blocked with a 403 if the content is seen in the payload BEFORE hitting process.php. Executing the form, I see the following in the error_log:

[Sun May 27 12:36:31 2007] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(spam|content|removed|for|list)" at REQUEST_BODY. [hostname "www.domain.com"] [uri "/process.php"] [unique_id "6UK2wkLbO5UAAAZsVgAAAAAA"]

This would 'normally' look good. Yet, looking in the access log, I clearly see a 302 code for process.php and I receive a mail with the spam content in it. So in essence, my request was still processed and the request made to process.php.

Removing mod_limitipconn and restarting Apache, mod_security behaves correctly. I did not have a problem with mod_limitipconn and mod_security-1.8.4

It almost appears that apache processes the request first.. than passes it to mod_security after it's done.

Reproducible: Always

Steps to Reproduce:
1. Install mod_security-2.1.1 and mod_limitipconn-0.22-r1
2. Add the following rule to 10_config.conf SecRule REQUEST_BODY "(spam|content|removed|for|list)" "log,auditlog,deny,phase:2,status:403"
3. Restart apache and trigger the rule by submitting a form with spam words listed in the regex SecRule

100% reproducible.

Actual Results:  
Apache passed request to process.php, processing of web files, no 403 is presented to the browser. Security is completely bypassed.

Expected Results:  
Blocked request with a 403 status before process.php was touched.

Current packages and versions:

[ebuild   R   ] net-www/mod_security-2.1.1  USE="-doc" 0 kB
[ebuild   R   ] net-www/mod_limitipconn-0.22-r1  7 kB
[ebuild   R   ] net-www/apache-2.0.58-r2  USE="apache2 mpm-prefork ssl -debug -doc -ldap -mpm-itk -mpm-leader -mpm-peruser -mpm-threadpool -mpm-worker (-selinux) -static-modules -threads" 4,652 kB

While testing I removed all additional configs for mod_security, and went with extremely basic config (10_config.conf)

SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType (null) text/html text/plain text/xml
SecResponseBodyLimit 524288
SecDefaultAction "phase:2,log,deny,status:403"
SecServerSignature "Apache"
SecRule REQUEST_BODY "(spam|content|removed|for|list)" "log,auditlog,deny,phase:2,status:403"
SecUploadDir /tmp
SecUploadKeepFiles Off
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^[45]"
SecAuditLogType Serial
SecAuditLog logs/modsec_audit.log
SecAuditLogParts "ABIFHZ"
SecArgumentSeparator "&"
SecCookieFormat 0
SecRequestBodyInMemoryLimit 131072
SecDebugLog             logs/modsec_debug.log
SecDebugLogLevel        3
SecDataDir /tmp
SecTmpDir /tmp
Comment 1 lou 2007-05-29 15:00:12 UTC
I contacted security@modsecurity.org, and Ivan Ristic responded by saying the following:

Ivan Ristic - "I've looked briefly at the source code of mod_limitipconn and it would appear that this module is not compatible with ModSecurity in the current version (as far as blocking is concerned). This is not unusual. Apache has an incredibly rich API that allows modules to significantly change the way requests are processed and it appears that mod_limitipconn does this."

He also mentioned that an upgrade to handle this will be created. I replied asking if this will be version upgrade or if a patch would be applied to 2.1.1 source.. haven't heard back but will report once I do.
Comment 2 lou 2007-05-31 21:51:53 UTC
Created attachment 120825 [details]
ebuild for portage overlay that includes the patch

proposed modified ebuild
Comment 3 lou 2007-05-31 21:53:42 UTC
Created attachment 120827 [details, diff]
patch created by mod_security team to address mod_limitipconn module issue

Patch to address mod_limitipconn module. This problem might exist with other modules that process requests, so might not be limited to mod_limitipconn
Comment 4 lou 2007-05-31 21:55:53 UTC
Will adding the patch and updating the mod_security-2.1.1.ebuild in portage be a possibility? They stated that this bug will be fixed in the next release (not sure if that is going to be 2.2.0 or something further ahead).

I also wanted to point out that the mod_Security bypass might happen with other modules similar to mod_limitipconn.
Comment 5 Benedikt Böhm (RETIRED) gentoo-dev 2007-06-15 18:22:01 UTC
fixed in 2.1.1-r1
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-08-24 06:53:36 UTC
Reopen, the patch is faulty and broke the whole thing, see Bug 189995.
Comment 7 Benedikt Böhm (RETIRED) gentoo-dev 2007-09-08 08:10:52 UTC
mod_security-2.1.2 in cvs, should be fixed