[False Positive ID 20020] Execution error - PCRE limits exceeded on WHMCS pages

Free Modsecurity rules - Comodo Web Application Fi
1

Hello,

Before switching to the CWAF rules I was using the Atomicorp Realtime (Paid) rules with which I never experienced such error message.

Now, with the CWAF rules, for every WHMCS page I visit (no matter if it’s the client area or the admin area), I get a Execution error - PCRE limits exceeded (-8): (null).

I have already configured my modsec.conf with:

SecPcreMatchLimit 200000
SecPcreMatchLimitRecursion 200000

and my php.ini with:

pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000

however the error still comes up. There’s also another user in WHT who’s experiencing the same issue - so I don’t think I’m alone.

Here’s the complete audit log (I have changed IPs, hostnames, cookie data for safety):

Rule 70e4528 [id "20020"][file "/var/cpanel/cwaf/rules/cwaf_05.conf"][line "45"] - Execution error - PCRE limits exceeded (-8): (null).

[02/Jan/2014:18:15:02 +0000] UsWspKINnKwAAVHoOW4AAABB 94.xxx.xxx.172 15879 162.xxx.xxx.172 443
--37febb21-B--
GET /admin-area-url/clients.php HTTP/1.1
Host: xxxxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xxxxx/admin-area-url/supporttickets.php
Cookie: sortdata=xxxxxxxxxxxx
Connection: keep-alive

--37febb21-F--
HTTP/1.1 200 OK
X-Powered-By: PHP/5.4.23
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: WHMCSFD=xxxxxxxxxxxx; path=/; httponly
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

--37febb21-H--
Message: Rule 70e4528 [id "20020"][file "/var/cpanel/cwaf/rules/cwaf_05.conf"][line "45"] - Execution error - PCRE limits exceeded (-8): (null).
Stopwatch: 1388686500650444 1862140 (- - -)
Stopwatch2: 1388686500650444 1862140; combined=257009, p1=2509, p2=254233, p3=31, p4=194, p5=41, sr=0, sw=1, l=0, gc=0
Producer: ModSecurity for Apache/2.7.5 (http://www.modsecurity.org/).
Server: Apache
Engine-Mode: "ENABLED"

The rule itself is

SecRule REQUEST_HEADERS:Cookie "[at]rx ^(.*;)*=(;.*)*$" \
        "id:20020,\
        msg:'COMODO WAF: see rule description',\
        phase:1,\
        deny,\
	status:403,\
        log"

and line 45 is the “log” line.

PS: None of the Cookie or Set-Cookie data contain “[at]rx”.

2

Hello George.

Thank you very much for reporting.

We will check this issue and fix it with next rules update.

3

Somehow did not experience this issue on .30, and our PCRE match limit is a little lower, 150k

4

Using Atomic delayed and see the same Execution error - PCRE limits exceeded (-8): (null).

SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 50000
and also in php.ini
pcre.backtrack_limit=100000
pcre.recursion_limit=100000

5

Please, check rules v.032
If you still get false positive ID 20020 please provide your Cookies and do not forget to secure cookie values by replacing chars with ‘#’ or ‘x’ for example.

6

Today I upgraded to the 0.33 rules and the PCRE errors still kept coming, so after some reading I took a different approach to see if it made any difference. Removed the settings from modsec2.usr.conf and added a separate conf as per…

http://datlinux.blogspot.co.nz/2013/04/modsecurity-rule-execution-error-pcre.html

Double check the servers main php.ini

pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000

Restarted apache & mysql & error were still happening on just 2 rules 20020 & 20042

With more reading I found this:

Rule execution error - PCRE limits exceeded (-8): (null).

This is an internal limit to prevent a special type of DOS attack on the WAF itself. This is not caused by any of the rules. This is caused by the content the rules are inspecting. In certain cases, the content may be so complex that the WAF is stopping itself from doing too much work which could lead to a DOS attack on the system itself. If your system is generating these kinds of errors, it means you need to set the limits higher on your system, while it is beyond the scope of this article, another solution is to reduce the complexity of the content you are inspecting.

It is also possible this is occurring due to an actual DOS attack on your system. If you are certain this is not a DOS attack, simply increase these limits accordingly for your system. For example:

SecPcreMatchLimit 250000
SecPcreMatchLimitRecursion 250000

You may have to increase these limits for your system if you continue to get PCRE limit errors.

I did the increases incrementally up to 1000000 but PCRE errors still happening, the only other thing I did find was that if errors still happened then it’s more and likely issues with the rule itself :frowning:

7

On an upgrade to 0.34 this morning, I see that 20020 & 20042 have changed numbers now: 220020 & 220042

Both still showing the PCRE errors

Rule 7f98858 [id “220042”][file “/var/cpanel/cwaf/rules/cwaf_05.conf”][line “86”] - Execution error - PCRE limits exceeded (-8): (null).
Rule 7f8b438 [id “220020”][file “/var/cpanel/cwaf/rules/cwaf_05.conf”][line “55”] - Execution error - PCRE limits exceeded (-8): (null).

8

Next update should fix this issue.

9

Great news

I tried adding the id 220020 in Global White List of the CMC, but seems to have no effect.

10

In the new version 0.35 the problem still persists

POST /whmcs/admin/index.php HTTP/1.1
Message: Rule bd7e3f8 [id "220020"][file "/var/cpanel/cwaf/rules/cwaf_05.conf"][line "55"] - Execution error - PCRE limits exceeded (-8): (null).
11

Nothing for me this time…not seeing the constant build up in the logs because after the update I get:

“No entries found in /usr/local/apache/logs/modsec_audit.log:” :cry:

edit
After the update it states that httpd was restarted, I had to restart it again before logs started showing entries again.

I can also confirm that I’m no longer seeing the PCRE entries in the log file :slight_smile:

12

Excluding rule 220020 results in an error when trying to restart httpd (v0.35, but happened with previous versions too).

13

Probably you have old version of PCRE lib. Try to update PCRE lib.

14

I tried on a different server with a newer pcre lib and the error is the same:

AH00526: Syntax error on line 5 of /var/cpanel/cwaf/etc/httpd/global/zzz_exclude_global.conf: Invalid command '220020', perhaps misspelled or defined by a module not included in the server configuration
15

Seems syntax of your exclude file is incorrect. To exclude rule 220020 please add following strings:

<LocationMatch .*>
SecRuleRemoveById 220020

16

Corrected the syntax and still doesn’t seem to work properly. Does it require a specific version of mod_sec? Any other prerequisites other than prce lib update?

17

Hello guys!

We are having the same problem with the rule 220020

Rule ce50298 [id “220020”][file “/var/cpanel/cwaf/rules/cwaf_05.conf”][line “55”] - Execution error - PCRE limits exceeded (-8): (null).

I set up SecPcreMatchLimit and SecPcreMatchLimitRecursion, yet the problem continues.

I’ve added the rule in the whitelist, but also didn’t work.

Nothing seems to work for this rule!

18

Have you restarted Apache after updating exclude list?

Please also look to my post here and check your configuration: https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/exclusion-manager-not-excluding-ver-034-t101192.0.html;msg734319#msg734319

19

This issue persists with the standard config and httpd restarted on various servers.

20

Only one server this error persists [line “56”]

Rule daa4978 [id "220020"][file "/var/cpanel/cwaf/rules/cwaf_05.conf"][line "56"] - Execution error - PCRE limits exceeded (-8): (null).