Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ModSecurity memory leak #236

Closed
vncloudsco opened this issue Jan 12, 2021 · 38 comments
Closed

ModSecurity memory leak #236

vncloudsco opened this issue Jan 12, 2021 · 38 comments
Assignees

Comments

@vncloudsco
Copy link

Dear: dev team
I have to use modsec with nginx (nginx version 1.16.1) However, it takes about 2 weeks for us to run out of memory, the system did not self-release the ram. How can I fix it?

lsof command show

image

@zimmerle zimmerle self-assigned this Jan 12, 2021
@zimmerle
Copy link
Contributor

Hi @vncloudsco,

What is your ModSecurity version?

@vncloudsco
Copy link
Author

Dear: @zimmerle
I am using modsecurity v3 and nginx 1.16.1

I used the build method of @ejhayes

#117 (comment)

I cannot use the option --with-compat

@vncloudsco
Copy link
Author

We run the system for about 2 weeks as it runs out of memory.

@zimmerle
Copy link
Contributor

@vncloudsco is that version 3.0.4? are you happens to perform webserver reloads? Did you ever observed if the leaks are related to the reload?

@martinhsv
Copy link
Contributor

Hi @vncloudsco ,

There are some known memory leaks that have already been fixed in 3.1 development code, but are not yet in v3/master or in an official release.

Per @zimmerle's question if you're on 3.0.4, please mention whether you mean the official release (from Jan. 10, 2020) or if you mean current v3/master.

@Michal256
Copy link

Michal256 commented Jan 13, 2021

Similar problem here. Problem occurs with v1.0.1 connector, modsecurity version 3.0.4 on nginx 1.16.1.
Whenever the nginx server has a modsecurity module attached in configuration file for ex.

server {
    listen       8080;
    server_name  localhost;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/rules.conf;
}

and nginx -s reload command was run, x (M) * number of nginx servers (with modsecurity module attached) is the amount of memory that nginx is taking permanently. Without connecting the module to any of nginx servers, the problem does not occur.
Systemctl restart nginx command makes memory available again.

@zimmerle
Copy link
Contributor

Similar problem here. Problem occurs with v1.0.1 connector, modsecurity version 3.0.4 on nginx 1.16.1.

Running any particular ruleset? custom rules?

@Michal256
Copy link

Yes I got some custom ruleset and I'm basing on owasp-modsecurity-crs-3.2.0. I also just checked that after disabling the custom ruleset, problem still seems to exist.

@vncloudsco
Copy link
Author

@martinhsv My problem is the same with @Michal256 . When start running, the system has no problem. But after a period of use, the memory is overflowed specifically after 2 weeks of operation. I have tested it with many rule (comodo modsecurity and owasp-modsecurity-crs-3.2.0 ) sets but to no avail.

@martinhsv
Copy link
Contributor

If your memory leaks are not associated with rule reload, In v3.0.4 I am aware of the following less-used ModSecurity features that will leak memory:

setenv (action)
validateDTD (operator)
validateSchema (operator)

To my knowledge CRS does not use any of these, but depending on which rule sets you are using you
could try checking for them.

(All three of the above have been corrected in 3.1-experimental code -- i.e. not yet available in v3/master)

It may well be, however, that you are experiencing something not previously identified.

@vncloudsco
Copy link
Author

vncloudsco commented Jan 19, 2021

Dear: @martinhsv

Something is wrong, let me ask how can I build the library?
I run make command on modsec v3.1-experimental but got an error.

/bin/sh ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.  -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -DWITH_CURL       -DPCRE_HAVE_JIT    -I/usr/include/libxml2 -DWITH_LIBXML2    -g -O2 -MT parser/libmodsecurity_la-seclang-parser.lo -MD -MP -MF parser/.deps/libmodsecurity_la-seclang-parser.Tpo -c -o parser/libmodsecurity_la-seclang-parser.lo `test -f 'parser/seclang-parser.cc' || echo './'`parser/seclang-parser.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -DWITH_CURL -DPCRE_HAVE_JIT -I/usr/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT parser/libmodsecurity_la-seclang-parser.lo -MD -MP -MF parser/.deps/libmodsecurity_la-seclang-parser.Tpo -c parser/seclang-parser.cc  -fPIC -DPIC -o parser/.libs/libmodsecurity_la-seclang-parser.o
In file included from ../headers/modsecurity/anchored_set_variable.h:31:0,
                 from ../headers/modsecurity/transaction.h:44,
                 from ../headers/modsecurity/modsecurity.h:188,
                 from ../src/rule_unconditional.h:28,
                 from seclang-parser.yy:28,
                 from parser/seclang-parser.cc:41:
../headers/modsecurity/string_view.hpp:443:38: error: redeclaration 'bpstd::basic_string_view<CharT, Traits>::npos' differs in 'constexpr'
     basic_string_view<CharT,Traits>::npos;
                                      ^
../headers/modsecurity/string_view.hpp:85:32: error: from previous declaration 'bpstd::basic_string_view<CharT, Traits>::npos'
     static constexpr size_type npos = size_type(-1);
                                ^
../headers/modsecurity/string_view.hpp:443:38: error: declaration of 'constexpr const size_type bpstd::basic_string_view<CharT, Traits>::npos' outside of class is not definition [-fpermissive]
     basic_string_view<CharT,Traits>::npos;
                                      ^
make[3]: *** [parser/libmodsecurity_la-seclang-parser.lo] Error 1
make[3]: Leaving directory `/opt/ModSecurity/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/ModSecurity/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/ModSecurity/src'
make: *** [all-recursive] Error 1

@martinhsv
Copy link
Contributor

martinhsv commented Jan 29, 2021

Hi @vncloudsco ,

I have not seen that particular compile error.

One thing to pay attention to is the output of the ./configure step. The output may tell you about some critical dependency that is missing (although in this case I suspect that it won't).

One possibility is that what you are seeing is related to compiler version.

What is your compiler and version? (And what O/S and distribution are you on?)

If you are using gcc and the versioning seems to match, you may be hitting this compiler bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58541

Which is asserted to have been fixed in 7.1.0.

If that all seems to line up, you could try upgrading your compiler version.

@vncloudsco
Copy link
Author

@martinhsv
this configure setup

image

my os:

[root@nginx ModSecurity]# cat /etc/os-release 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

I cannot compile it. though can run in v3.0 version with no problems

@martinhsv
Copy link
Contributor

Hi @vncloudsco ,

Did you try checking your compiler version? E.g.

gcc --version

@vncloudsco
Copy link
Author

@martinhsv
sorry i for the late reply you can see my full error info here
owasp-modsecurity/ModSecurity#2530

@qjavax
Copy link

qjavax commented Mar 17, 2021

Hi @martinhsv @vncloudsco, i'm expirencing same issues with modsecurity enabled in nginx version 1.16.1 with libmodsecurity 3.0.4 and nginx-modesecurity module 1.0.1:
After 6 days of deployment nginx processes can reach even 10GB of memory usage (highly relatable with number of vhost running with modsec enabled * number of reloads). For example - nginx without modsec enabled uses 0.8-1GB of memory. With modsec rules enabled 1.2GB - 1.6GB (2405 rules loaded). But when reloading can reach even x3 times more memory and after some time memory will back to ALMOST 'normal' values. It seems like big memory leak in modsec/nginx-modsec module when reloading nginx.
Some useful information:

nginx version: nginx/1.16.1
built with OpenSSL 1.1.1 (compatible; BoringSSL) (running with BoringSSL)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/local/nginx/bin/nginx --pid-path=/usr/run/nginx.pid --lock-path=/usr/run/lock/nginx.lock --user=nobody --group=nobody --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-pcre-jit --with-file-aio --with-http_gzip_static_module --with-http_realip_module --with-http_ssl_module --with-http_addition_module --with-http_degradation_module --with-http_secure_link_module --with-http_stub_status_module --with-http_v2_module --with-http_v3_module --with-http_ssl_module --with-openssl=/tmp/makepkg/nginx/src/quiche/deps/boringssl --with-quiche=/tmp/makepkg/nginx/src/quiche --add-module=/tmp/makepkg/nginx/src/naxsi-untagged-afabfc163946baa8036f/naxsi_src --add-module=/tmp/makepkg/nginx/src/headers-more-nginx-module-0.33 --add-module=/tmp/makepkg/nginx/src/modsecurity-nginx-v1.0.1 --with-compat

gcc version 9.2.0 (GCC)

Number of vhost with memory usage after ~6 days of nginx uptime reloading ~once per 4 hours. I have no idea why only 2 of these servers have acceptable 1.2GB memory usage (with 0 modsec vhosts) but others doesn't.

Memory used [MB] 3146.43 4284.58 3791.75 3025.22 4097.7 4730.46 5034.52 3413.25 3271.38 5624.77 1375.09 1293.47 2775.79 2913.97 8311.8
Modsec vhosts 12 8 10 0 10 10 14 5 14 18 1 0 5 2 40

Screenshots from monitoring:
View pre modsec deployment to now:

big_uptime

View of manual nginx stop / nginx reloading:

manual_reloads

View of automatic reloads (~once per 4h, clear increase of memory usage):

automatic_reloads

@zimmerle
Copy link
Contributor

@qjavax thanks for the detailed report. is lmdb enabled? if so, may be related to owasp-modsecurity/ModSecurity#2520

@qjavax
Copy link

qjavax commented Mar 17, 2021

@zimmerle no I don't, i use nginx as a reverse proxy without lmdb, Only modules i have enabled are: headers-more-nginx-module, naxsi and ModSecurity-nginx

@zimmerle
Copy link
Contributor

@qjavax I meant to ask if you had lmdb enabled during the ModSecurity build. You can choose different backends for collections, one of the backends is the lmdb. There is this pull request on owasp-modsecurity/ModSecurity#2520 that aiming to fix a memory leak.

@qjavax
Copy link

qjavax commented Mar 18, 2021

@zimmerle oh sorry i didn't get your question. But still I don't have LMDB enabled in my modsecurity build I use almost default configuration):

ModSecurity -  for Linux
 
 Mandatory dependencies
   + libInjection                                  ....
   + SecLang tests                                 ....
 
 Optional dependencies
   + GeoIP/MaxMind                                 ....found 
      * (MaxMind) v1.4.2
         -lmaxminddb , -DWITH_MAXMIND 
      * (GeoIP) v1.6.12
         -lGeoIP , -I/usr/include/ 
   + LibCURL                                       ....found v7.66.0 
      -lcurl,  -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL
   + YAJL                                          ....found v2.1.0
      -lyajl , -DWITH_YAJL -I/usr/include/yajl 
   + LMDB                                          ....disabled
   + LibXML2                                       ....found v2.9.9
      -lxml2 -lz -llzma -licui18n -licuuc -licudata -lm -ldl, -I/usr/include/libxml2 -DWITH_LIBXML2
   + SSDEEP                                        ....found 
      -lfuzzy -L/usr/lib/, -DWITH_SSDEEP -I/usr/include
   + LUA                                           ....found v503
      -llua5.3 -L/usr/lib/, -DWITH_LUA -I/usr/include
 
 Other Options
   + Test Utilities                                ....enabled
   + SecDebugLog                                   ....enabled
   + afl fuzzer                                    ....disabled
   + library examples                              ....disabled
   + Building parser                               ....disabled
   + Treating pm operations as critical section    ....disabled

@qjavax
Copy link

qjavax commented Mar 25, 2021

@zimmerle do you want me to provide more information about this leak?

@vncloudsco
Copy link
Author

@zimmerle Do you need any more information? we still get the memory leak.

@zimmerle
Copy link
Contributor

zimmerle commented Apr 6, 2021

@qjavax @vncloudsco It would be amazing to have a valgrind output of this particular issue. It will speed up the investigation process.

@qjavax
Copy link

qjavax commented Apr 9, 2021

Hi @zimmerle, yes I could provide some valgrind output but i'm having trouble building nginx with debug symbols. I tried adding:
--with-debug \ --with-cc-opt="-O0 -g"
as well with:
CFLAGS="-g -O0" CCFLAGS="-g -O0" CPPFLAGS="-g -O0" ./configure \
to my configure but it still can't get debugging symbols in my nginx binary.
Do you have any idea how to compile nginx binary with debug symbols?

@pawelrosada
Copy link

@zimmerle Do you need any more information about leak?

@defanator
Copy link
Collaborator

JFTR:
#260 (comment)
#260 (comment)

(there is a reproducible way to observe a number of leaks not necessary related to any regex processing - see the above comments; just came across to this ticket while searching for any existing unresolved memory leaks reports)

@liudongmiao
Copy link

@vncloudsco @defanator See #277 and owasp-modsecurity/ModSecurity#2710.

I have fixed in #277 by a workaround.

@szilard6
Copy link

@liudongmiao If I apply the patch to the current master branch the memory leak gets fixed but starts to block a basic login page with TX:ANOMALY_SCORE + audit log stop working.

Looks like this leak was reported really long time ago - in the meantime new version was also released - NOT everybody is affected by this memory leak problem?

Anybody has any instructions how I can install with no memory leak ?

@airween
Copy link
Member

airween commented Aug 18, 2022

@liudongmiao If I apply the patch to the current master branch the memory leak gets fixed but starts to block a basic login page with TX:ANOMALY_SCORE + audit log stop working.

may be your WAF has started to work? :)

Looks like this leak was reported really long time ago - in the meantime new version was also released - NOT everybody is affected by this memory leak problem?

Now I checked, and it runs since only few minutes, I sent few requests, but there nothing changed in the memory usage of Nginx.

Anybody has any instructions how I can install with no memory leak ?

I'm using Debian, and installed packages from here.

Note: the libmodsecurity package does not use the LMDB.

@baudneo
Copy link

baudneo commented Oct 19, 2022

Still memory leaks in current v3/master branch.

I compiled modsec using base configuration and memory isn't freed on nginx -s reload. If anyone has any suggestions or unmerged PR's I'm all ears.

@liudongmiao
Copy link

@baudneo The main memory leak should be fixed in owasp-modsecurity/ModSecurity@e9a7ba4.

And for discussion, you can read this issue: owasp-modsecurity/ModSecurity#2728

@baudneo
Copy link

baudneo commented Oct 20, 2022

@liudongmiao hi! I've built modsec v3/master branch with those fixes applied and still have the memory leak. I have opened a new issue about it but the maintainer seemed to take offense to me opening the issue.

If I only enabled modsec once in the root http {} block and modsec isn't compiled with lmdb the memory leak is only 10-12MB per reload. With db I get 200+MB leak per reload. I have a user that is loading modsec directives and different rule files in server or location blocks and they are reporting up to 300MB leak on every reload.

@szilard6
Copy link

After I updated to the latest ubuntu the memory leak issue got fixed .... (22.04)

@S0obi
Copy link

S0obi commented Oct 26, 2022

I just tried what @szilard6 proposed, unfortunately, I cannot observe any meaningful difference between the two setups (Ubuntu 20.04 vs 22.04). I am not even sure that the Operating system is actually making any significant difference.

@martinhsv
Copy link
Contributor

I would be quite surprised upgrading the OS version would eliminate issues with reload-without-restart.

@martinhsv
Copy link
Contributor

@vncloudsco ,

I never did see you answer zimmerle's question "are you happens to perform webserver reloads?"

If this report is related to nginx reload, I would prefer to close this as a duplicate.

@vncloudsco
Copy link
Author

Dear: @martinhsv
we still get it every time we reload nginx it forces us to restart nginx for it to go away. I noticed the problem is not completely fixed and this issue should be open.

I also update my OS 20.04 and 22.04 and didn't see any change as @szilard6 mentioned

@martinhsv
Copy link
Contributor

Closing as duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests