MSC_PCRE_LIMITS_EXCEEDED error triggering after upgrading to version 4.12.0

[etabacchi]

What happened:

Hello, i have recently updated my nginx-controller hosted on a gke cluster to version 4.12.0 of the helm chart from version 4.10.1, the moment i did this change some of our application calls started returning a 403 error from nginx and checking the logs this is what i've got.

The only significant change i made to my configuration was adding the property annotations-risk-level: "Critical" to the controller config because otherwise i was getting problems on the certificates.

In order to partially fix this i had to increase the default secPcreMatchLimit to 10k from the default of 1k and while some calls stopped returning the error others didnt.

Reverting the version to the 4.10.1 makes the 403 errors disappear.

What did i expect:

I wasnt able to find anything relevant to this problem in the release notes so i would expect the behavior to be the same between the two versions given that the default for the secPcreMatchLimit seems to be set at 1000 for both, so to summarize my questions are:

1. What changed between versions 4.10.1 and 4.12.0 that could cause this problem?
2. What is considered a safe enough value for the secPcreMatchLimit property?

[strongjz]

4.10.1 and 4.12.0 are helm charts, so it may easy to see changes between the controller versions in those helm charts.

controller-v1.12.0 is set in 4.12.0 and controller-v1.10.2 in 4.10.1, the full change log is here

From what I have read The PCRE Match limit is meant to reduce the chance for a DoS attack via Regular Expressions.

Are you sure that the ingress wasn't under a heavy load?

The docs do not recommend a value https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v3.x)#user-content-SecPcreMatchLimit

From the preaapi Manpage https://linux.die.net/man/3/pcreapi

The match_limit field provides a means of preventing PCRE from using up a vast amount of resources when running patterns that are not going to match, but which have a very large number of possibilities in their search trees. The classic example is the use of nested unlimited repeats.

Internally, PCRE uses a function called match() which it calls repeatedly (sometimes recursively). The limit set by match_limit is imposed on the number of times this function is called during a match, which has the effect of limiting the amount of backtracking that can take place. For patterns that are not anchored, the count restarts from zero for each position in the subject string.

The default value for the limit can be set when PCRE is built; the default default is 10 million, which handles all but the most extreme cases. You can override the default by suppling pcre_exec() with a pcre_extra block in which match_limit is set, and PCRE_EXTRA_MATCH_LIMIT is set in the flags field. If the limit is exceeded, pcre_exec() returns PCRE_ERROR_MATCHLIMIT.

The match_limit_recursion field is similar to match_limit, but instead of limiting the total number of times that match() is called, it limits the depth of recursion. The recursion depth is a smaller number than the total number of calls, because not all calls to match() are recursive. This limit is of use only if it is set smaller than match_limit.

[strongjz]

/kind support
/triage needs-information
/priority backlog