8

I've been having tonnes of issues with Mod Security. I am busy writing a CMS for a project at work and while developing a page to edit a certain database record I kept getting 403 errors. After hours of banging my head against my desk, adjusting bits of code I finally just changed the script to which my form was being posted, to contain a simple echo "test";. Even submitting to this simple page was kicking up a 403 error. I messed about with my form and I eventually found that if I reduced the amount of data I was posting the form submitted fine (In particular I reduce the amount of text within a textarea).

After checking the logs (Yep, this wasn't the first thing I did - sigh) I noticed that I was getting numerous errors from ModSecurity, such as:

[Mon Aug 12 16:34:45 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Failed to access DBM file "/etc/httpd/logs//global": Permission denied [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkAlW1shFcAAHTMK80AAAAF"]
[Mon Aug 12 16:34:45 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Failed to access DBM file "/etc/httpd/logs//ip": Permission denied [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkAlW1shFcAAHTMK80AAAAF"]
[Mon Aug 12 17:11:33 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Rule execution error - PCRE limits exceeded (-8): (null). [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkJNW1shFcAAHXUMHkAAAAH"]
[Mon Aug 12 17:11:33 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Access denied with code 403 (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED" required. [file "/etc/httpd/conf.d/mod_security.conf"] [line "93"] [msg "ModSecurity internal error flagged: TX:MSC_PCRE_LIMITS_EXCEEDED"] [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkJNW1shFcAAHXUMHkAAAAH"]

I've been messing around, Googling and changing rules for days to no avail. The only thing I seem to be able to do is turn ModSecurity off for this vhost. This is fine by me while I'm developing the CMS, but in production this isn't really something I want to do. Does anyone have any ideas on what is causing this issue and how to sort it? The logs seem to point at some kind rules to do with regular expression limits, but since changing my post receiving script to just print out the word test I'm not doing anything with them (Though I have tried upping the limits through SecPcreMatchLimit and SecPcreMatchLimitRecursion). It seems rather that there's something wrong with the amount of data I am sending through.

Jonathon
  • 15,873
  • 11
  • 73
  • 92
  • I'm having the same problem and like right now I have 2 Apache processes running at 100% CPU... On an 8 core, it's not too bad in a way, but it also means that some users are not being served! – Alexis Wilke Jan 13 '14 at 00:07

2 Answers2

3

I've just resolved a similar issue, with a large post triggering PCRE limit errors in multiple rules. I feel it's wrong for mod-security to then flag the request as malicious just because it blew up!

I raised the two settings you mentioned from the default to 500,000 from the default of 1,500 as advised in this post, and it solved my problem.

The default values for the PCRE Match limit are very, very low with ModSecurity. You can got to 500K usually without harming your set. But for your information: The PCRE Match limit is meant to reduce the chance for a DoS attack via Regular Expressions. So by raising the limit you raise your vulnerability in this regard, but the PCRE errors are much worse from a security perspective. I run with 500K in prod usually:

SecPcreMatchLimit 500000 SecPcreMatchLimitRecursion 500000

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/656

Also see https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecPcreMatchLimit

scipilot
  • 6,681
  • 1
  • 46
  • 65
2

I had a similar issue with PCRE module a few weeks ago and it was related to backtrack_limits.

I assume SecPcreMatchLimit and SecPcreMatchLimitRecursion are related to mod_security, but did you try upping the values for pcre module in your php.ini file or during PHP execution time?

pcre.backtrack_limit and pcre.recursion_limit

You could also confirm if the issue is related to PCRE limits with the following function preg_last_error()

You can see more here: http://php.net/manual/en/function.preg-last-error.php

and here: http://www.php.net/manual/en/pcre.constants.php

I hope this helps.

RickyCheers
  • 334
  • 2
  • 6
  • Sorry, it's been a while since I posted this issue. I set those PCRE values in the php.ini file I think (Certainly didn't do it during execution with `ini_set()` or anything). Also.. I'm unable to even do `preg_last_error()` since the page even 403s for a simple `echo "test";` – Jonathon Oct 11 '13 at 16:18
  • 1
    My issue seems to be that ModSecurity is treating the data I am sending through as suspicious for some reason rather than actually having anything to do with PCRE – Jonathon Oct 11 '13 at 16:21
  • 2
    Half of this answer is wrong. It definitively has nothing to do with PHP since Apache is running the ModSecurity module. Actually Jonathon specifically says that if he turns off ModSecurity his page works just fine. – Alexis Wilke Jan 13 '14 at 00:05
  • @AlexisWilke is right, this has "nothing" to do with PHP. It would be the PCRE compiled into mod_security/2 that is hitting the limit. It's definitely the SecPcreMatchLimit setting - this resolved it for me. – scipilot Aug 17 '17 at 06:13
  • We are sing .net APIs and as of now we have enabled the WAF in detection node. We are getting several logs for (Execution error - PCRE limits exceeded), so the concern is that when we put the WAF on prevention mode so will WAF block these request for which we are getting "Execution error - PCRE limits exceeded" or will it pass on the request to next pipeline. – Himanshu Jain Mar 04 '21 at 07:41