On Thu, Mar 25, 2010 at 3:53 PM, <AFaller@excelsior.edu>
Hi All -
I'm running mod_security 2.5.12 with
the CRS 2.0.6 in my test environment (my production environment still has
1.x CRS). I'm having issues with a home grown application built upon
Apache MyFaces 1.x that produces a rediculous amount of post parameters
and the size of these parameters is massive. These applications often generate
"PCRE limits exceeded" in my audit logs. Can this be due
to the size and number of parameters?
I've upped SecPcreMatchLimit and SecPcreMatchLimitRecursion,
but it still occurs (Currently at 5000). What was the old limit prior
The default in 2.5.12 can be changed at configure time : --enable-pcre-match-limit=value
and enable-pcre-match-limit-resursion=value. The --disable-pcre-match-limit-recursion and
-disablepcre-match-limit configure limit revert-back to the default of the PCRE library. For PCRE the default (from the README) are
" PCRE has a counter that can be set to limit the amount of resources it uses.
If the limit is exceeded during a match, the match fails. The default is ten
million. You can change the default by setting, for example,
on the "configure" command. This is just the default; individual calls to
pcre_exec() can supply their own value. There is more discussion on the
pcreapi man page.
. There is a separate counter that limits the depth of recursive function calls
during a matching process. This also has a default of ten million, which is
essentially "unlimited". You can change the default by setting, for example,
Recursive function calls use up the runtime stack; running out of stack can
cause programs to crash in strange ways. There is a discussion about stack
sizes in the pcrestack man page."
So, besides the old limit, IMHO could be useful to put x10 your values in mod_security as PCRE has values much largest by default.