Bug 773483

Summary: PCRE limits seem broken with simple input
Product: [Fedora] Fedora EPEL Reporter: long
Component: mod_securityAssignee: Othman Madjoudj <athmanem>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6CC: athmanem, mfleming+rpm, redhat-bugs, stjepan.gros
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-09-11 03:12:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
HTML form that should trigger problem none

Description long 2012-01-11 22:53:52 UTC
Created attachment 552251 [details]
HTML form that should trigger problem

Description of problem:
I have a simple HTML form I will attach.  When trying to submit this form the request is always forbidden if the text inside of the <textarea> is more than somewhere in the range of 740 - 907 characters.  If it is less than that then the form works correctly.  The modsec_audit.log says:

--d421a611-H--
Message: Pattern match "^([^;\s]+)" at REQUEST_HEADERS:Content-Type. [file "/etc/httpd/modsecurity.d/base_rules/modsecurity_crs_30\
_http_policy.conf"] [line "63"] [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-\
urlencoded"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_A\
ppSensor/EE2"] [tag "PCI/12.1"]
Message: Rule execution error - PCRE limits exceeded (-8): (null).
Message: Rule execution error - PCRE limits exceeded (-8): (null).
Message: Rule execution error - PCRE limits exceeded (-8): (null).
Message: Rule execution error - PCRE limits exceeded (-8): (null).
Message: Access denied with code 403 (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED" required. [file "/etc/htt\
pd/conf.d/mod_security.conf"] [line "93"] [msg "ModSecurity internal error flagged: TX:MSC_PCRE_LIMITS_EXCEEDED"]
Action: Intercepted (phase 2)
Stopwatch: 1326321198117273 21026 (999* 20744 -)
Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5.
Server: Apache/2.2.15 (Red Hat)

--d421a611-Z--

which seems to indicate that I need to raise SecPcreMatchLimit and/or SecPcreMatchLimitRecursion in /etc/httpd/conf.d/mod_security.conf.  So I tried changing them from 1000 to 15000000000 and the same problem still happens.  I'm no PCRE expert but that doesn't seem to be working right.


Version-Release number of selected component (if applicable):
mod_security-2.5.12-2.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. put attached HTML file in your web server
2. access HTML file in web browser
3. try to submit form in web page
  
Actual results:
HTTP 403 error

Expected results:
web page displays correctly.


Additional info:

Comment 1 Nick 2012-03-02 23:37:40 UTC
This issue seems to exist in mod_security-2.5.12-3.el5.i386 as well.

Comment 2 Stjepan Gros 2012-05-22 12:46:21 UTC
The issue is present also in mod_security 2.5.12-3.el5.

Here is the POST request that triggers the bug:

POST /ib/servlet HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: localhost
Content-Length: 56

svrha=502%2C503%2C495%2C498%2C499-5+kom+-JAM%C4%8CEVINA 

I also reported this issue to upstream:

https://www.modsecurity.org/tracker/browse/MODSEC-309

Comment 3 Stjepan Gros 2012-06-19 12:07:17 UTC
I got response to upgrade to the newest version.

Is it possible to update mod_security to newest version, i.e. 2.6.6?

Comment 4 Othman Madjoudj 2012-09-08 22:32:57 UTC
Can check if this issue is still reproducible with the latest mod_security and mod_security_crs from epel-testing.

Comment 5 long 2012-09-10 22:37:28 UTC
I just tried with mod_security-2.6.7-1.el6.x86_64 from epel and the problem does not seem to happen any longer.