reload memory usage

[adamjacobmuller]

Hello,

We are running ModSecurity@1edd3570e11e9bb2b6d86b249232b24917a4b0ac and ModSecurity-nginx@abbf2c47f6f3205484a1a9db618e067dce213b89 with nginx 1.13.1.

I'm attaching the rule set + modsecurity configuration as well.

When reloading nginx, memory usage will sometimes grow exponentially and easily overwhelm the resources on the server (~100GB of ram). This does not happen 100% of the time, but, is trivial to reproduce just by doing while true;do nginx -s reload;done, nginx will cause the system to OOM reliably after a few minutes.

rules.zip

[zimmerle]

Testing with cc1d220b408fe73a4e1950b71848772d505d6ce0. Not able to reproduce. Do you mind to shared your configuration summary?

[adamjacobmuller]

Hi @zimmerle,

Could I share offline with you the full configuration, or just give you access to an environment where I can demonstrate it?

-Adam

[zimmerle]

Hi @adamjacobmuller,

Sure it won't be a problem. But please, before do that, it will be very good if you can upgrade to the latest version and check if everything is working as expected [or not]. If not, that will be good if you can narrow down the problem to the exactly configuration that is leading to the problem.

[alexdavydov]

Hello @zimmerle.

While running continuous reloads with libmodsec loaded as a dynamic module, stock modsecurity.conf and CRS3.0.2 loaded, I can see growing RES footprint. It doesn't happen with the same Nginx binary without ngx_http_modsecurity_module.so loaded.

# ps aux | grep nginx | grep -v grep | awk '{print $6}'
15344
16220
16220
# for i in {1..100}; do nginx -s reload; done
# ps aux | grep nginx | grep -v grep | awk '{print $6}'
33092
31156
31156

ModSecurity 04f7009 ;
ModSecurity-nginx owasp-modsecurity/ModSecurity-nginx@a2a5858

Configure options for libmodsecurity:
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/
usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pcre=/usr/bin/pcre-config --with-curl=/usr/bin/curl-config

Default CentOS 7 CXXFLAGS: '-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'

ModSecurity - v2.9.0-912-g04f7009 for Linux

Mandatory dependencies

• libInjection ....v2.9.0-912-g04f7009
• SecLang tests ....04f7009

Optional dependencies

• GeoIP ....found v1.5.0
  -lGeoIP , -I/usr/include/
• LibCURL ....found v7.29.0
  -lcurl , -DWITH_CURL
• YAJL ....found v2.0.4
  -lyajl , -DWITH_YAJL
• LMDB ....not found
• LibXML2 ....found v2.9.1
  -lxml2 -lz -lm -ldl, -I/usr/include/libxml2 -DWITH_LIBXML2

Other Options

• Test Utilities ....enabled
• SecDebugLog ....enabled
• afl fuzzer ....disabled
• library examples ....enabled
• Building parser ....disabled

Nginx version is 1.11.10, configure options are pretty much the same as in Fedora package (https://src.fedoraproject.org/rpms/nginx/blob/master/f/nginx.spec), give or take an optional module.

Let me know if you need more information.

[victorhora]

Thanks for the info @alexdavydov.

I was able to reproduce it here. I ran some tests with Valgrind and is also flagging some memory leaks when ngx_http_modsecurity is loaded:

==34396== 41,879 (88 direct, 41,791 indirect) bytes in 1 blocks are definitely lost in loss record 704 of 711
==34396== 3,184,513 (6,952 direct, 3,177,561 indirect) bytes in 79 blocks are definitely lost in loss record 711 of 711
==34396== LEAK SUMMARY:
==34396== definitely lost: 7,040 bytes in 80 blocks
==34396== indirectly lost: 3,219,352 bytes in 863 blocks
==34396== possibly lost: 115,576 bytes in 15 blocks
==34396== still reachable: 199,722 bytes in 3,462 blocks
==34396== suppressed: 0 bytes in 0 blocks

As of now I'm inclined to believe that the issue might be on the connector rather than libModSecurity. Will investigate a bit more.

[zimmerle]

Please check 1ad9525. There was a fixed at #1563 which is likely to fix this behavior as well.

[ozermetin]

Please check 1ad9525. There was a fixed at #1563 which is likely to fix this behavior as well.

This problem persists. We have the same kind of memory leak during reloads. We have an environment for you to replicate the same issue.

[zimmerle]

Hi @ozermetin,

Thanks for the report. Re-opening this issue.