Skip to content

ssdeep + SecUploadKeepFiles On = Memory leaks? #1288

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

Closed
meatlayer opened this issue Dec 20, 2016 · 1 comment
Closed

ssdeep + SecUploadKeepFiles On = Memory leaks? #1288

meatlayer opened this issue Dec 20, 2016 · 1 comment
Assignees
Labels
2.x Related to ModSecurity version 2.x TBF by libmodsec
Milestone

Comments

@meatlayer
Copy link

meatlayer commented Dec 20, 2016

Hello,

After enabling SecUploadKeepFiles in the apache configuration to use fuzzy hash (ssdeep) verification, i found crazy memory leaks.

Apache/2.4.10 (Debian) mpm-itk/2.4.7-02 OpenSSL/1.0.1t
ModSecurity for Apache/2.9.1

I tried to change the settings for these options in the config. I increased values, then do reduced values. But it had no effect. The leak has not disappeared.

SecRequestBodyInMemoryLimit 512000
SecRequestBodyNoFilesLimit 512000
SecResponseBodyLimit 32000000

Below you can see how the increased memory consumption of an apache process at load time CSV file with a maximum size of 15MB:

============================================
LA=94
PIDS=2
CPU=7.2%
MEM=79.9%
SQL=0%

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ UID COMMAND (TOP)
-----------------------------------------------------------------------
9773 to*y 30 10 28.344g 0.025t 3520 D 7.2 79.9 0:53.49 1652 /usr/sbin/apache253 -D php53 -k restart
4332 to*y 20 0 110728 2052 0 S 0.0 0.0 0:00.12 1652 proftpd: to*y - 82.193.139.*: IDLE


Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request (APACHE)
-----------------------------------------------------------------------
13-0 16769 0/952/2951 W 0.04 142 0 0.0 17.50 55.07 82.193.139.* lamp***b.ru:8083 POST /admin/index.php?route=catalog/suppler/start&token=19c5a91

============================================

LA=7
PIDS=2
CPU=100%
MEM=49.6%
SQL=0%

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ UID COMMAND (TOP)
-----------------------------------------------------------------------
32550 u23**5 30 10 16.503g 0.015t 4648 R 100.0 49.5 0:26.41 1870 /usr/sbin/apache2 -k restart
332 u23**5 20 0 151772 48804 4852 S 0.0 0.1 0:08.40 1870 proftpd: u23**5 - 176.53.193.*: IDLE


Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request (APACHE)
-----------------------------------------------------------------------
12-2 26889 0/128/1540 W 0.00 26 0 0.0 1.60 23.83 176.53.193.* tech***ecko.ru:8070 POST /admin/index.php?route=extension/installer/upload&token=ew
============================================

On the server 32GB of RAM. On load average = 5-10. When playing problems, a sharp increase in LA > 50-100 and huge memory consumption and further care in the SWAP, so long as you don't kill the process.
Maybe someone knows how it is possible to fix it?
Need do change settings or is it a bug?
It should be noted that if the disable SecUploadKeepFiles option, the problem with the memory leak disappears.

@meatlayer meatlayer changed the title SecUploadKeepFiles On = Memory leaks? ssdeep + SecUploadKeepFiles On = Memory leaks? Apr 19, 2017
@victorhora victorhora self-assigned this Sep 22, 2018
@victorhora victorhora added TBF by libmodsec 2.x Related to ModSecurity version 2.x labels Sep 22, 2018
@victorhora victorhora added this to the v2.9.3 milestone Sep 22, 2018
@victorhora
Copy link
Contributor

This shouldn't be a concern with libModSecurity. Ssdeep support and the fuzzyHash operator are fully implemented since a9d54c3. See #997 fore more information.

libModSecurity (aka v3) is already officially released: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.2 (3.0.3 upcoming)

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.x Related to ModSecurity version 2.x TBF by libmodsec
Projects
None yet
Development

No branches or pull requests

2 participants