On Thu, Mar 25, 2010 at 3:53 PM, <AFaller@excelsior.edu> wrote:

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 to 2.5.12?

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,

  --with-match-limit=500000

  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,

  --with-match-limit-recursion=500000

  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.

hth