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

SecStreamInBodyInspection brings memory leak #1316

Closed
AirisX opened this issue Feb 6, 2017 · 1 comment
Closed

SecStreamInBodyInspection brings memory leak #1316

AirisX opened this issue Feb 6, 2017 · 1 comment
Assignees

Comments

@AirisX
Copy link

AirisX commented Feb 6, 2017

Hi,

I'm using openresty/1.11.2.2 with nginx_refactoring branch module. I found memory leak while testing file upload. After numerous experiments, I discovered the cause of the problem. It is the directive "SecStreamInBodyInspection On" witin the rule file 25_Init_AppsInitialization.conf:

#---------------------------------------------------------------
#Comodo ModSecurity Rules
#Copyright (C) 2016 Comodo Security solutions All rights reserved.
#
#The COMODO SECURITY SOLUTIONS Mod Security Rule Set is distributed under
#THE COMODO SECURITY SOLUTIONS END USER LICENSE AGREEMENT,
#Please see the enclosed LICENCE file for full details.
#---------------------------------------------------------------
#This is a FILE CONTAINING CHANGED or MODIFIED RULES FROM THE:
#OWASP ModSecurity Core Rule Set (CRS)
#---------------------------------------------------------------

SecDefaultAction \
        "phase:1,deny,log"

SecDefaultAction \
        "phase:2,deny,log"

SecRule REQUEST_COOKIES:PHPSESSID "!@rx ^$" \
        "id:219900,rev:9,msg:'COMODO WAF: start track phpsession||%{tx.domain}|%{tx.mode}',phase:2,capture,pass,setsid:'%{MATCHED_VAR}',nolog"

SecRule REQUEST_COOKIES_NAMES "@rx ^wordpress_([0-9a-fA-f]{32})$" \
        "id:219901,rev:9,msg:'COMODO WAF: Start track session id|%{TX.1}|%{tx.domain}|%{tx.mode}',phase:2,capture,pass,setsid:'%{TX.1}',setvar:'SESSION.wp_session=1',setvar:'TX.WordPress=1',expirevar:'SESSION.wp_session=300',nolog"

SecRule REQUEST_COOKIES:MoodleSession "!@rx ^$" \
        "id:219902,rev:9,msg:'COMODO WAF: start track MoodleSession||%{tx.domain}|%{tx.mode}',phase:2,capture,pass,setsid:'%{MATCHED_VAR}',setvar:'SESSION.moodlesession=%{MATCHED_VAR}',nolog"

SecRule &SESSION:joomla_session "@eq 0" \
        "id:219904,rev:9,chain,msg:'COMODO WAF: Start tracking Joomla! session||%{tx.domain}|%{tx.mode}',phase:2,pass,nolog,t:'none'"
SecRule REQUEST_COOKIES:/^[a-f0-9]{32}$/ "@rx ^[a-z0-9]{26}$" \
        "setsid:'%{MATCHED_VAR}',setvar:'SESSION.joomla_session=1',expirevar:'SESSION.joomla_session=3600',t:'none'"

SecStreamInBodyInspection On
SecAction \
        "id:219000,phase:2,pass,setvar:'tx.xmlrpc_watch_period=300',setvar:'tx.xmlrpc_requests_limit=5',setvar:'tx.xmlrpc_block_timeout=600',nolog"

SecRule REQUEST_COOKIES_NAMES "@rx ^sess([0-9a-f]{32})$" \
        "id:219010,rev:1,msg:'COMODO WAF: Drupal App Initialization||%{tx.domain}|%{tx.mode}',phase:2,capture,pass,setsid:'%{TX.1}',setvar:'TX.drupal=1',setvar:'SESSION.drupal=1',expirevar:'SESSION.drupal=300',nolog,t:'none',t:'lowercase'"

Here are the results of measurements.
Before loading test:

              total        used        free      shared  buff/cache   available
Mem:           1832         424        1064          13         342        1156
Swap:          7999         350        7649

59.5508 MB      root    46429 nginx: master process 
60.832 MB       wuser    46430 nginx: worker process
60.832 MB       wuser    46431 nginx: worker process

After loading test:

             total        used        free      shared  buff/cache   available
Mem:           1832        1382         110          13         339         198
Swap:          7999         350        7649

59.5508 MB      root    46429 nginx: master process 
60.832 MB       wuser    46431 nginx: worker process
1017.28 MB      wuser    46430 nginx: worker process

As you can see the worker process with pid 46430 ate almost 1 GB of the memory.
When I switched off the described directive the problem is gone.

@victorhora
Copy link
Contributor

Hi, @AirisX

Please use ModSecurity-nginx instead of version 2.9.1. SecStreamInBodyInspection is no longer supported on libModSecurity (aka v3). By default v3 will try to use stream whenever it is possible.

Further information about ModSecurity-nginx is available here: https://github.com/SpiderLabs/ModSecurity-nginx

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

No branches or pull requests

2 participants