nginx/1.7.2 with modsecurity-2.8.0 high cpu load

[ghost]

When i want to use mod securtiy for filtering REQUEST_BODY i must enable SecRequestBodyAccess in order to be able to filet the requests.

When i set 'SecRequestBodyAccess On' when i make POST request with post data not bigger than a word the nginx worker hags at 100% CPU usage and does nothing. I tried to strace the worker and it seems to make 3 read from /dev/urandom and then does nothing.

Even if i have no rules that process REQUEST_BODY with SecRequestBodyAccess enabled the worker uses 100% CPU.

If i disable SecRequestBodyAccess there is no such problem but filters that include REQUEST_BODY are NOT working.

[ghost]

Hi again,

here is the back trace of the worker who hangs:
(gdb) bt
#0 0x0000000000498907 in ap_http_in_filter ()
#1 0x00000000004ce85d in read_request_body ()
#2 0x000000000049f990 in hook_request_late ()
#3 0x00000000004993cc in modsecProcessRequestBody ()
#4 0x00000000004975ec in ngx_http_modsecurity_process_request ()
#5 0x0000000000497b5a in ngx_http_modsecurity_handler ()
#6 0x000000000043953f in ngx_http_core_generic_phase ()
#7 0x00000000004350f5 in ngx_http_core_run_phases ()
#8 0x000000000043f9e3 in ngx_http_process_request ()
#9 0x0000000000440250 in ngx_http_process_request_line ()
#10 0x000000000042488a in ngx_event_process_posted ()
#11 0x000000000042a088 in ngx_worker_process_cycle ()
#12 0x0000000000428ad4 in ngx_spawn_process ()
#13 0x000000000042a254 in ngx_start_worker_processes ()
#14 0x000000000042ac55 in ngx_master_process_cycle ()
#15 0x000000000040cf9f in main () at src/core/nginx.c:407
(gdb)

After the worker hangs the strace and ltrace don't output anything.

[ghost]

This back trace is from refactoring branch

[zimmerle]

Hi @Pilotat, do you have others nginx modules installed in this intense? or just the ModSecurity module?

It happens 100% of the time?

[ghost]

Hi @zimmerle,

our nginx is build with:
./configure
--prefix=/etc/nginx
--sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid
--lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp
--user=nginx
--group=nginx
--with-http_ssl_module
--with-http_realip_module
--with-http_addition_module
--with-http_sub_module
--with-http_dav_module
--with-http_flv_module
--with-http_mp4_module
--with-http_gunzip_module
--with-http_spdy_module
--with-http_gzip_static_module
--with-http_random_index_module
--with-http_secure_link_module
--with-http_stub_status_module
--with-mail
--with-mail_ssl_module
--with-file-aio
--with-ipv6
--with-debug
--add-module=<path_to_mod_security>
'--with-cc-opt=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic '

The request that we make is:
curl -d "a" domain.tld

Every single curl request like the one provided triggers this issue, when SecRequestBodyAccess is enabled.
We also tried with gzip disabled, but the issue persist.

[zimmerle]

No longer a concern in libModSecurity. Marking it as won't fix for 2.x. Further information about libModSecurity available here:
https://github.com/SpiderLabs/ModSecurity/tree/v3/master