Memory issue with specific CRS rules (variable expansion in compiled operators)

28 views
Skip to first unread message

Andrew Howe

unread,
Oct 29, 2020, 10:05:48 AM10/29/20
to modsecurity-core...@owasp.org
Hello,

I've been investigating a memory issue with a production proxy server
which uses ModSecurity 2.9 on Apache and CRS 2 (I've also had the same
problem with CRS 3).

The amount of 'used' memory on the server increases linearly over
time. The httpd process is responsible for the used memory increase.
'Used' memory slowly approaches 100% over the space of two months or
so. A periodic restart of the httpd process temporarily relieves the
problem.

Disabling the entire CRS stops the memory issue. I started enabling
and disabling each rule to find which one was causing the problem. I
think rule 960010 is the problem: if rule 960010 is disabled then the
problem goes away. If *only* rule 960010 is *enabled* and everything
else (the rest of the CRS) is disabled then the memory problem
appears.

I think the problem could be related to performing variable expansion
in a regular expression operator:
SecRule TX:0 "!^%{tx.allowed_request_content_type}$"
If that variable expansion is removed and the full contents of
"tx.allowed_request_content_type" are inserted then the memory problem
disappears.

To test this further, I used a ModSecurity setup with the whole CRS
disabled and 100 copies of rule 960010 manually defined. This
amplified the problem massively and caused memory use to reach 100%
within a few hours (as quickly as a few minutes, even, if I modify the
rule to inspect the entire REQUEST_HEADERS collection.)

I've also tested using the CRS 3 equivalent rule, 920420. Using many
copies of that rule also caused the same memory problem.

I'm wondering if this is a known issue or if I've made a silly mistake
somewhere. Any advice would be greatly appreciated.

Thanks,
Andrew Howe

--

Andrew Howe
Loadbalancer.org Ltd.
www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064

Christian Folini

unread,
Nov 16, 2020, 5:00:42 AM11/16/20
to Andrew Howe, modsecurity-core...@owasp.org
Hey Andrew,

I think you never got a response for this.

Personally, I was not aware of this problem. Or rather I know of 'used' memory
issues with ModSec on certain installations. But my customers were never able
to track it down to an individual rule. So this is interesting.

My previous knowledge said that it had to do with many rules being loaded in
different VHs.

Your explanation is much more to the point. Unless it's a separate problem of
course. Which is also possible.

Given ModSec2 is no longer actively developed, I take it this won't be fixed.
Even more so as a restart is a viable workaround.

Best,

Christian
> --
> You received this message because you are subscribed to the Google Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-...@owasp.org.
> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/CADi1syAUhXM7oib%3DEc_-SxHg%3DBMH-t6nVriix8pqO1Yr_0%2BKnw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages