Execution Error - PCRE limit exceeded

What could be the cause of this? Suggested fix other than disabling the rules or raising the pcre limit to some absurdly high value?

Thanks in advance!

Rules 220041 & 220042
Ubuntu 14.04 running Apache 2.4 with modsecurity 2.7.7 and latest cwaf rules.


[Fri Oct 16 10:51:46.286443 2015] [:error] [pid 9222:tid 140160008120064] [client x.y.z.z] ModSecurity: Rule 7f799cd13550 [id “220042”][file “/usr/share/cwaf/rules/01_Global_Generic.conf”][line “80”] - Execution error - PCRE limits exceeded (-8): (null). [hostname “artistformedling.se”] [uri “/kontakt/”] [unique_id “ViC6oi4Va@UAACQGa9AAAABS”]
[Fri Oct 16 10:51:46.286398 2015] [:error] [pid 9222:tid 140160008120064] [client x.y.z.z] ModSecurity: Rule 7f799cdb2090 [id “220041”][file “/usr/share/cwaf/rules/01_Global_Generic.conf”][line “77”] - Execution error - PCRE limits exceeded (-8): (null). [hostname “artistformedling.se”] [uri “/kontakt/”] [unique_id “ViC6oi4Va@UAACQGa9AAAABS”]

Relevant cwaf config

SecRule REQUEST_BODY “@rx .type.yaml.— !ruby/hash:ActionController::Routing::RouteSet::NamedRouteCollection.\n.!ruby/object:ActionController::Routing::Route.\n\ssegments.\n\srequirements.
“id:220041,msg:‘COMODO WAF: found CVE 2013-0156 attack’,phase:2,deny,status:504,log”

SecRule REQUEST_BODY “@rx .type.yaml.— !ruby/hash:ActionDispatch::Routing::RouteSet::NamedRouteCollection.\n.!ruby/object:OpenStruct.\n\stable.\n.defaults.
“id:220042,msg:‘COMODO WAF: found CVE 2013-0156 attack’,phase:2,deny,status:504,log”


Well this rules targeting Ruby on Rails vulnerability (CVE 2013-0156)
If you don’t have Ruby on your server you can safe disable them.

If you want to dig deeper:

PCRE limits exceeded is common problem in high-load environment. It happens when content analyzed by security rule with Perl regular expression is too complex or number of requests is too high. To avoid Deny of Service (DoS) on your server here is PCRE limits on guard.

For example, using a simple ‘aaaaaaaaaaaaaaaaaab’ style pattern in a parameter payload repeated 50 times makes a request go from 0.1 seconds to 5.5 seconds with a bad regex and 150,000 limit set. Making the pattern repeat 100 times yields 22.4 seconds to process it. During this time the Apache process is using 100% of one CPU core.

Higher value of PCRE limits means Apache will spend more time processing requests before limits reached. This can lead to DoS.
Lower value of PCRE limits means less probable DoS situation, but some requests will be dropped with “PCRE limits exceeded (-8): (null)” error.
So it’s important to find which value of PCRE limits will be good for your server. Not allowing DoS attacks and keeping “PCRE limits exceeded” errors at low level.

Also here is good cPanel forum thread about issue:
mod_security Rule execution error - PCRE limits exceeded (-8): (null). | cPanel Forums

In brief (for cPanel):

Here is recommended steps for tuning PCRE limits: 1. First, update your perl modules on server by running /scripts/checkperlmodules script several times (until you see no error messages)
  1. Add to your PHP.INI the following commands:
    pcre.backtrack_limit = 10000000
    pcre.recursion_limit = 10000000

  2. Try to change parameters in /usr/local/apache/conf/modsec2.conf to (alternatively you can use cPanel CWAF plugin->“Security Engine” tab):
    SecPcreMatchLimit 50000
    SecPcreMatchLimitRecursion 5000

If this not help try to change SecPcreMatchLimit and SecPcreMatchLimitRecursion to higher values. (SecPcreMatchLimitRecursion < SecPcreMatchLimit)

Regards, Oleg

I run a WAF on a reverse proxy for customers to block attacks so it should block all kinds of attacks.
I already do remove some rules, it’s just that I thought I should ask about a general advice here first.

I dont have that ‘/scripts/checkperlmodules’, and I already increased the pcre limit ten fold from Trustwaves recommendation :-).

I have
/etc/modsecurity/modsecurity.conf:SecPcreMatchLimit 10000
/etc/modsecurity/modsecurity.conf:SecPcreMatchLimitRecursion 10000
/etc/apache2/mods-available/security2.conf: SecPcreMatchLimit 1000000
/etc/apache2/mods-available/security2.conf: SecPcreMatchLimitRecursion 1000000

Not sure what takes precedence but Trustwaves general advice is a mere 1000.

So removing (SecRemove*) the rule is what’s left then?


Hmm, yes for proxy configuration it’s wise to not disable any protection but processing more rules require more resources.

Seems you have two mod_security configuration (/etc/modsecurity/modsecurity.conf and /etc/apache2/mods-available/security2.conf)
Please check your Apache config. Which one is loading?
If both loads simultaneously only last option will take effect.
I’m not sure you need two mod_security configuration files :slight_smile:
Also can you please describe your installation (Operating system, Web server, Web control panel (webmin, Plesk etc), how rules was installed (plugin, vendor, just downloaded) )

Regards, Oleg

Rules 220041 & 220042
Ubuntu 14.04 running Apache 2.4 with modsecurity 2.7.7 and latest cwaf rules.

It’s a cluster of apache nodes which we can scale up almost infinitely high so resource usage is not a prime concern right now. We have http/https load balancer which balances traffic to a set of identically configured modsecurity apache hosts, which then in turn reverse proxies to the real backends. No control panel.

/etc/apache2/mods-enabled/security2.conf is the governing file. It initiates mod_security, further includes /etc/modsecurity/modsecurity.conf and lastly cwaf rules :-).

# Default Debian dir for modsecurity's persistent data SecDataDir /var/cache/modsecurity
    SecPcreMatchLimit 1000000
    SecPcreMatchLimitRecursion 1000000

    # Main config options
    IncludeOptional /etc/modsecurity/*.conf

    # Comodo Waf attack patterns
    Include "/usr/share/cwaf/etc/cwaf.conf"


Thank you for info provided.

So now following values are in effect (from /etc/modsecurity/modsecurity.conf):
SecPcreMatchLimit 10000
SecPcreMatchLimitRecursion 10000

Tuning PCRE Limits is tricky business and performed for certain server :slight_smile:
As I see values are equal but SecPcreMatchLimitRecursion have to be < SecPcreMatchLimit (as described in recommendation).

Regards, Oleg