MODSEC-11: Here so I remember to look when I have time.

From Marty B:
{quote}
I have observed a very odd thing for a long time.

My www. sites generally are CNAMEs pointing to the A record.
The raw domain will work also and be served with redirection
by apache mod_rewrite. Pretty common practice methinks.

When the www.site is accessed, everything works as expected.
When the raw domain is accessed the rules don't work the
same and I lose some function. Why, I wonder? Strange.

I do not insert modsec stuff anywhere into my vhosts
configuration and prefer not to. It is all global and uses
the core rules except for a few modifications.

I have this phenomenon well documented online, however I can
only guess what is causing this behavior. The last years'
collected data looks like 2 different sites for each one I
have. Obviously something is amiss in the mix.

My config stuff is far too tweaked to comfortably publish on
the Internet; don't ask. I will share privately with
interested developers only/PGP.

Marty B.
{quote}

{quote}
I have attached a tar.gz for your eyes only.
Nothing is obfuscated. The raw stuff.
This contains all my configs, etc in a text file.
Sorry; I only squeezed it to sneak it past mail software.

If you discover a nice configuration error on my part,
please feel free to obfuscate and post for others to learn
from too. (I am capable of splendid mistakes:)

Please keep any further communications regarding this issue
in context by emailing me discretely, and thanks much for
your very kind interest.

Best regards,

Marty B.
{quote}

I have the file, but not attaching to this issue (too sensitive says Marty).

MODSEC-1: Under some error conditions (such as disk full, etc) temporary files (request body) are not removed from disk.

Hi,

I have a problem with nginx and mod_security module. After reloading nginx configuration (kill -HUP ) all files opened by mod_security are opened once again without closing the old ones. That means at some point we hit the limit of open file descriptors, in my real life scenario I leak over 300 files on each reload.

Here are my sample configs just to illustrate the problem:

nginx.conf
user www-data www-data;
worker_processes 6;
worker_rlimit_nofile 200000;

error_log /var/log/nginx/error.log debug;

events {
worker_connections 16384;
multi_accept on;
use epoll;
}

http {
server {
listen 80;
location / {
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;
return 555;
}
}
}

modsecurity.conf:
SecDebugLog /var/log/waf/events.log

In this situation after each configuration reload I am leaking open files:

www-data@dev03 ~ # lsof | grep nginx | wc -l; kill -HUP ps aux | grep 'nginx: master process' | grep -v grep | awk '{print $2}'; sleep 2; lsof | grep nginx | wc -l
361
368

I am using Ubuntu 12.04 LTS and nginx _openresty 1.4.2.1

(DEPLOY)www-data@dev03:~# nginx -V
nginx version: ngx_openresty/1.4.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled

I will be happy to provide other information if necessary.

Regards,
Kiril

the STREAM_INPUT_BODY variable does not currently allow you to manipulate REQUEST_URI or REQUEST_HEADER data. While you can use mod_headers for cookie manipulation there is no way to manipulate GET parameters. Can this functionality be added directly to ModSecurity?

There are lua errors when compiling with nginx. The following gist

https://gist.github.com/4438255

Has the relevant details. This is the current remotes/trunk branch of the ModSecurity git repo and a source tarball of nginx 1.2.6. The config flags are in the gist.

While implementing MODSEC-58 there was incomplete code added, which lead to a compiler error in apache2/apache2_config.c.

../apache2/apache2_config.c:3470:1: error: unterminated argument list invoking macro "AP_INIT_TAKE1"
../apache2/apache2_config.c:2814: error: 'AP_INIT_TAKE1' undeclared here (not in a function)
../apache2/apache2_config.c:2814: error: expected '}' at end of input

It seems that you forgot to add a ")," after line 2819 in apache2/apache2_config.c

WinSrv 2008 R2 x64 IIS7.5 with PHP 5.4 via FastCGI

I found this issue existed after enabled Modsec in web.config.
At first, I thought it might be caused by crs rules. However, even I only include modsecurity.conf, it still act the same.

Here are debug log during login process. The webpage couldn't respond until connection timed out.

Initialising transaction (txid 12538021364746957633). Transaction context created (dcfg 969290). First phase starting (dcfg 969290). Starting phase REQUEST_HEADERS. Recipe: Invoking rule 299ec08; [file "c:\inetpub\wwwroot\owasp_crs\modsecurity.conf"] [line "24"] [id "200000"]. Transformation completed in 0 usec. Executing operator "rx" with param "text/xml" against REQUEST_HEADERS:Content-Type. Operator completed in 0 usec. Rule returned 0. Second phase starting (dcfg 969290). Input filter: Reading request body. Input filter: Completed receiving request body (length 109). Starting phase REQUEST_BODY. Recipe: Invoking rule 299d168; [file "c:\inetpub\wwwroot\owasp_crs\modsecurity.conf"] [line "55"] [id "200001"]. Transformation completed in 0 usec. Executing operator "!eq" with param "0" against REQBODY_ERROR. Operator completed in 0 usec. Rule returned 0. Recipe: Invoking rule 29a04a8; [file "c:\inetpub\wwwroot\owasp_crs\modsecurity.conf"] [line "76"] [id "200002"]. Transformation completed in 0 usec. Executing operator "!eq" with param "0" against MULTIPART_STRICT_ERROR. Operator completed in 0 usec. Rule returned 0. Recipe: Invoking rule 29a44d0; [file "c:\inetpub\wwwroot\owasp_crs\modsecurity.conf"] [line "81"] [id "200003"]. Transformation completed in 0 usec. Executing operator "!eq" with param "0" against MULTIPART_UNMATCHED_BOUNDARY. Operator completed in 0 usec. Rule returned 0. Recipe: Invoking rule 29a5408; [file "c:\inetpub\wwwroot\owasp_crs\modsecurity.conf"] [line "95"] [id "200004"]. Rule returned 0. Hook insert_filter: Adding input forwarding filter (r 29a9440). Hook insert_filter: Adding output filter (r 29a9440).

So here is a question for you guys. I have nginx setup on a server and it is the core webservice daemon for sites on it. I am not using it as a proxy to another nginx instance or as a proxy to apache. What would one use for upstream, I do pass off to php-fpm but that is specific to that type of page content. Based on what I am seeing it seems as though the current implementation expects nginx to operate as a proxy. I would like to use modsecurity but I don't have need of a second nginx instance or a reverse proxy setup.

MODSEC-15: The {{SecRuleUpdateActionById}} example is incorrect:

{noformat}
SecRuleRemoveById RULEID ACTIONLIST
{noformat}

I cann't find the mod for nginx , where's it?

MODSEC-3: Often, you check one of the ARGS in the request. But current implementation is not so easy to use. I ended up to use a function like this.

function get_args()
-- Retrieve script parameters, create more easy-to-use dictionary...
local vars = m.getvars("ARGS")
local args = {}
for i = 1, #vars do
vars[i].name = vars[i].name:gsub("^ARGS:", "")
args[vars[i].name] = vars[i].value
end
return args
end

With this, you can write:

local args = get_args()
if args.comment:find("spam") then
return "comment spam: spam"
end

make test crashes with a segfault if configure was run with pcre jit enabled.
Crash happens in rx.t, e.g. in

./msc_test "-t" "op" "-n" "rx" "-p" "" "-D" "0" "-r" "1"

Stack shows that the problem is in apache2/re_operators.c:

998         rc = msc_fullinfo(regex, PCRE_INFO_JIT, &jit);
999         if ((rc != 0) || (jit != 1)) {

1000 *error_msg = apr_psprintf(rule->ruleset->mp,
1001 "Rule %pp [id "%s"][file "%s"][line "%d"] - "
1002 "Execution error - "
1003 "Does not support JIT (%d)",
1004 rule,((rule->actionset != NULL)&&(rule->actionset->id != NULL)) ? rule->actionset->id : "-",
1005 rule->filename != NULL ? rule->filename : "-",
1006 rule->line_num,rc);
1007 }

The rule used here has non-null actionset, but the id is set to 0xffffffff which can't be printed with %s.

The crash can be avoided by e.g. the following patch to tests/msc_test.c:

--- msc_test.c 2012-12-29 20:22:37.515480000 +0100
+++ msc_test.c 2012-12-29 20:23:32.392925000 +0100
@@ -325,9 +325,6 @@
*errmsg = apr_psprintf(g_mp, "Failed to create rule for op "%s": %s", name, *errmsg);
return -1;
}

• if (data->rule->actionset != NULL) {

•    data->rule->actionset->id = "1";
  

• }

/* Create a fake variable */
data->var = (msre_var *)apr_pcalloc(g_mp, sizeof(msre_var));

Note that I don't know why the test entered the error path in line 999 above. It shouldn't crash though.

I'm using modsecurity for apache 2.7.4 -- I compiled it from source.

I've got a custom rule loaded and working correctly, but only by NOT following the directions. Here's my apache directive for loading conf files

IfModule security2_module
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the .conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
Include "/etc/modsecurity/.conf" # (modsecurity.conf)
Include "/etc/modsecurity/v2.2.7/activated_rules/*.conf"
/IfModule

I've created symlinks of all the base_rules (*.conf and *.data) in the activated_rules directory.

I found some documentation on creating whitelists to deal with false positives here:
http://www.modsecurity.org/blog/archives/2007/02/handling_false.html
This indicated that the whitelist directives should be placed "after the modsecurity_crs_10_config.conf file but BEFORE the other Core Rules"

I used the following simple directive to test against:
SecRule SCRIPT_FILENAME "omniture-index-action" "phase:1,log,allow,id:25000002"
I just wanted to make sure I could log a hit with this rule.

When this script was placed in a file (and symlinked to the activated_rules directory) named modsecurity_crs_15_customrules.conf--and restarting apache--I'd get nothing.
However, when I changed the file name to modsecurity_crs_00_customrules.conf--and restarting apache--then I'd get the audit log entry I'd expect.

So, this load order does NOT work for me:
~ more files ~
modsecurity_crs_10_setup.conf
modsecurity_crs_15_customrules.conf
~ more files ~

However, the exact same directive in this load order does work:
~ more files ~
modsecurity_crs_00_customrules.conf
modsecurity_crs_10_setup.conf
~ more files ~

I've I misread something somewhere? Am I not doing the apache configs correctly? Or, is the documentation mistaken or out of date?

Nginx 1.4.1
ModSecurity 2.7.4

server {
listen 80;
server_name www.xxxx.co;

    location / {
        ModSecurityEnabled on;
        ModSecurityConfig modsecurity.conf;
        proxy_pass http://111.111.111.111:80/;
        proxy_set_header Host www.xxxx.co;
        proxy_read_timeout 180s;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }

}

2013/06/07 16:59:34 [debug] 656#0: *4 http init upstream, client timer: 0
2013/06/07 16:59:34 [debug] 656#0: *4 http script copy: ""
2013/06/07 16:59:34 [debug] 656#0: *4 http script copy: ""
2013/06/07 16:59:34 [debug] 656#0: *4 http script copy: "Connection: close^M
"
2013/06/07 16:59:34 [debug] 656#0: *4 http script copy: "Content-Length: "
2013/06/07 16:59:34 [debug] 656#0: *4 http script var: "122"
2013/06/07 16:59:34 [debug] 656#0: *4 http script copy: "^M
"
2013/06/07 16:59:34 [alert] 656#0: *4 no upstream configuration, client: 111.111.111.111, server: blog.xxxx.co, request: "POST /wp-login.php HTTP/1.1", host: "blog.xxxx.co", referrer: "http://blog.xxxx.co/wp-login.php"

It looks like http script engine not parse proxy_*** configure.

After installing last nginx module (2.7.3) on high load nginx process blocks and stops respoding to requests (may be if backend responds longer than usual).
Here is backtrace:

#0  0x000000000041fecc in ngx_event_pipe_write_to_downstream (p=0x2b40a30,
    do_write=45353568) at src/event/ngx_event_pipe.c:551
#1  ngx_event_pipe (p=0x2b40a30, do_write=45353568)
    at src/event/ngx_event_pipe.c:33
#2  0x00000000004453b0 in ngx_http_upstream_process_upstream (r=0x2af7010,
    u=0x2aefe20) at src/http/ngx_http_upstream.c:2947
#3  0x00000000004454c2 in ngx_http_upstream_handler (ev=0x2b33fe0)
    at src/http/ngx_http_upstream.c:956
#4  0x000000000041e606 in ngx_event_process_posted (
    cycle=<value optimized out>, posted=0x2b40a60)
    at src/event/ngx_event_posted.c:40
#5  0x000000000041e4d6 in ngx_process_events_and_timers (cycle=0x19c1230)
    at src/event/ngx_event.c:274
#6  0x000000000042417a in ngx_worker_process_cycle (cycle=0x19c1230,
    data=<value optimized out>) at src/os/unix/ngx_process_cycle.c:807
#7  0x0000000000422a9c in ngx_spawn_process (cycle=0x19c1230,
    proc=0x4240a7 <ngx_worker_process_cycle>, data=<value optimized out>,
    name=0x5df196 "worker process", respawn=-3)
    at src/os/unix/ngx_process.c:198
#8  0x00000000004236e2 in ngx_start_worker_processes (cycle=0x19c1230, n=8,
    type=-3) at src/os/unix/ngx_process_cycle.c:362
#9  0x000000000042469b in ngx_master_process_cycle (cycle=0x19c1230)
    at src/os/unix/ngx_process_cycle.c:136
    argv=<value optimized out>) at src/core/nginx.c:412
(gdb)

commenting out ngx_http_modsecurity_header/filter/ngx_http_modsecurity_body_filter resolves the problem.

sample config:

server {
...
ModSecurityEnabled on;
ModSecurityConfig /etc/modsecurity.conf;

    location / {
       proxy_pass http://backend;
    }
}

OWASP-CRS base rules used with default modsecurity.conf and some features disabled:

SecRequestBodyAccess On
SecResponseBodyAccess Off
SecDefaultAction "phase:2,deny"
SecRuleEngine On
SecPcreMatchLimit 5000
SecPcreMatchLimitRecursion 5000
SecAuditEngine Off

validate_quotes in apache2/msc_multipart.c will set flag_invalid_quoting if a filename contains a single quote.

A request with the following header will set the flag_invalid_quoting.

Content-Disposition: form-data; name="userfile"; filename="AS'4360.pdf"

This is header is correct and valid according to RFC 2045, RFC 2183 and RFC 822.

MODSEC-18: Go beyond the discrete inspection model we currently have implemented, and toward streaming inspection. The idea is that the code would generate a number of streams, each streaming transaction data but in a slightly different way. Examples include:

• Request body (after dechunking and decompression)
• Response body (before dechunking and decompression)
• File content (one stream per uploaded file)

Implementation:

• SecStreamingInspection On|Off - on by default.
• SecStreamMatch TARGETS PATTERNS ACTIONS
• We would reuse variable names for TARGETS.
• PATTERNS is a list of @pm patterns.
• The ACTIONS part would support a limited set of actions (e.g. no flow control ones, no phases).
• We would initially support inspection of raw streams, but, at a later date, we can implement streaming transformation operators to allow for streaming transformation pipelines.
• All instances of SecStreamMatch targeting the same stream (and, later, using the same tfn operators) would be combined into a single matching tree.

Stream inspection would occur in real-time, as the content is being processed. There are two advantages of this approach:

1. We can block on streaming-only mode (MODSEC-17).
2. Makes pre-qualification easier (and faster).

When i submit a request like

www.192.168.0.102/admin

and the rule follow is fired:

SecRule REQUEST_URI "(^/admin)"
"id:'10',
t:none,
phase:1,
log,
deny,
status:403"

I see in debug log:

[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][5] Rule 89f6670: SecRule "REQUEST_URI" "@rx (^/admin)" "phase:1,auditlog,id:10,t:none,log,deny,status:403"
[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][4] Transformation completed in 4 usec.
[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][4] Executing operator "rx" with param "(^/admin)" against REQUEST_URI.
[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][9] Target value: "/usr/local/nginx/html/admin?"
[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][6] Ignoring regex captures since "capture" action is not enabled.
[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][4] Operator completed in 44 usec.
[04/Apr/2013:10:17:41 --0700] [/sid#89e6618][rid#8a2f780][/admin][4] Rule returned 0.

Hello,

i configured the compiler to build the file using:

./configure -–with-apxs=/usr/local/apache2/bin/apxs -–with-apr=/usr/local/apr/bin/apr-1-config –with-apu=/usr/local/apr/bin/apu-1-config

Executing make fires the error:

/usr/bin/ld: cannot find -lexpat
collect2: ld returned 1 exit status
make[2]: *** [mod_security2.la] Error 1
make[2]: Leaving directory /home/downloads/modsecurity-apache_2.7.0/apache2' make[1]: *** [all] Error 2 make[1]: Leaving directory/home/downloads/modsecurity-apache_2.7.0/apache2'
make: *** [all-recursive] Error 1

for latest version 2.7.1 as well as for 2.7.0. Searching for this error through Google brought this hint:

lexpat should be read as -l expat

Now my question is:

Is this error caues by a typo in mod_security sources and how to fix it?

Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux

ModSec 2.7.5 and Nginx 1.4.2

I have an Apache backend and it receives my file uploads and requests if the file is below 8k. Only got the basic modsecurity.conf loaded without any rules. If I set the SecRequestBodyAccess = Off even those pass through. Succesful upload:

[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Initialising transaction (txid AcAcAGl3AcAcAcAcAcAcAcAc).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Transaction context created (dcfg 7f35a9f41980).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Starting phase REQUEST_HEADERS.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Second phase starting (dcfg 7f35a9f41980).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Input filter: Reading request body.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Multipart: Created temporary file 1 (mode 0600): /var/log/modsecurity_workdir/20130912-151049-AcAcAGl3AcAcAcAcAcAcAcAc-file-vIn5DC
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][5] Adding request argument (BODY): name "submit", value "Submit"
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Request body no files length: 150
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Input filter: Completed receiving request body (length 4719).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Starting phase REQUEST_BODY.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Hook insert_filter: Adding input forwarding filter (r 7f35a9d950a0).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Hook insert_filter: Adding output filter (r 7f35a9d950a0).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Input filter: Forwarding input: mode=0, block=0, nbytes=-1 (f 7f35a9d962b0, r 7f35a9d950a0).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Input filter: Forwarded 4719 bytes.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Input filter: Sent EOS.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Input filter: Input forwarding complete.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Starting phase RESPONSE_HEADERS.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Output filter: Not buffering response body for unconfigured MIME type "text/html".
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Output filter: Completed receiving response body (non-buffering).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Starting phase RESPONSE_BODY.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Output filter: Output forwarding complete.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Initialising logging.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Starting phase LOGGING.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Recording persistent data took 0 microseconds.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Audit log: Ignoring a non-relevant request.
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Multipart: Cleanup started (remove files 1).
[12/Sep/2013:15:10:49 +0300] [/sid#7f35a9f410a0][rid#7f35a9d950a0][/upload_file.php][4] Multipart: Deleted file (part) "/var/log/modsecurity_workdir/20130912-151049-AcAcAGl3AcAcAcAcAcAcAcAc-file-vIn5DC"

failed upload:

[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Initialising transaction (txid AcAcATAcccAcAcRcvYAIpcAc).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Transaction context created (dcfg 7f35a9f41980).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Starting phase REQUEST_HEADERS.
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Second phase starting (dcfg 7f35a9f41980).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Input filter: Reading request body.
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Multipart: Created temporary file 1 (mode 0600): /var/log/modsecurity_workdir/20130912-151248-AcAcATAcccAcAcRcvYAIpcAc-file-qmZcxo
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][5] Adding request argument (BODY): name "submit", value "Submit"
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Request body no files length: 149
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Input filter: Completed receiving request body (length 8893).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Starting phase REQUEST_BODY.
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Hook insert_filter: Adding input forwarding filter (r 7f35a9d8d0a0).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Hook insert_filter: Adding output filter (r 7f35a9d8d0a0).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Input filter: Forwarding input: mode=0, block=0, nbytes=-1 (f 7f35a9d8e2b0, r 7f35a9d8d0a0).
[12/Sep/2013:15:12:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Input filter: Forwarded 8192 bytes.
[12/Sep/2013:15:13:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Initialising logging.
[12/Sep/2013:15:13:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Starting phase LOGGING.
[12/Sep/2013:15:13:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Recording persistent data took 0 microseconds.
[12/Sep/2013:15:13:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Audit log: Ignoring a non-relevant request.
[12/Sep/2013:15:13:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Multipart: Cleanup started (remove files 1).
[12/Sep/2013:15:13:48 +0300] [/sid#7f35a9f410a0][rid#7f35a9d8d0a0][/upload_file.php][4] Multipart: Deleted file (part) "/var/log/modsecurity_workdir/20130912-151248-AcAcATAcccAcAcRcvYAIpcAc-file-qmZcxo"

Nginx 1.4.1
ModSecurity 2.7.4

Before reload nginx returns correctly, after reload empty reply from server and segfault in logs

kernel: [2765388.969856] nginx[15475]: segfault at 70 ip 00007f159738a7ab sp 00007fff29ef02d0 error 4 in libapr-1.so.0.3.8[7f159736c000+35000]

MODSEC-14: The t:cssDecode transformation in trunk needs to be reviewed/updated, then backported to 2.5.

• Verify against RFC
• Make sure handles full/half ASCII

when building modsecurity without curl will cause following error
mlogc.c:32:10: fatal error: 'curl/curl.h' file not found

nginx 1.5.5 + modsecurity 2.7.5 in CentOS 5.9
'''
objs/ngx_modules.o
-lpthread /usr/src/www/nginx/modsecurity-apache_2.7.5/nginx/modsecurity/
../../standalone/.libs/standalone.a -lapr-1 -L/usr/lib -laprutil-1 -lpcre -L/usr
/local/lib -lxml2 -lz -lm -ldl -lcrypto
/usr/src/www/nginx/modsecurity-apache_2.7.5/nginx/modsecurity/../../standalone/.
libs/standalone.a(standalone_la-msc_crypt.o): In function inject_hashed_respons e_body': /usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:10 79: undefined reference toxmlOutputBufferGetSize'
/usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:11
10: undefined reference to xmlOutputBufferGetSize' /usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:11 22: undefined reference toxmlOutputBufferGetSize'
/usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:11
32: undefined reference to xmlOutputBufferGetContent' /usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:11 35: undefined reference toxmlOutputBufferGetSize'
/usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:10
81: undefined reference to xmlOutputBufferGetSize' /usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:10 93: undefined reference toxmlOutputBufferGetSize'
/usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:11
03: undefined reference to xmlOutputBufferGetContent' /usr/src/www/nginx/modsecurity-apache_2.7.5/standalone/../apache2/msc_crypt.c:11 06: undefined reference toxmlOutputBufferGetSize'
collect2: ld returned 1 exit status
make[1]: *** [objs/nginx] Error 1
make[1]: Leaving directory `/usr/src/www/nginx/nginx-1.5.5'
make: *** [build] Error 2
'''

MODSEC-2: It looks like modsecurity drops reporting the server hostname in its logs when the HTTP request doesn't contain a Host: header. This leads to mistakes when parsing the error logs (in my case). I'd like to see something put there - perhaps "SERVER_NAME" - better yet, the defaultHost Apache is set for (as that would actually be the server the attack was against)

e.g

SecRule &REQUEST_HEADERS:User-Agent "@eq 0"
"deny,log,auditlog,status:404,msg:'Request Missing a User-Agent
Header',,id:'960020',severity:'4'"

If the attacker uses a Host: header but no User-Agent, you get

ModSecurity: Access denied with code 404 (phase 2). Operator EQ matched
0 at REQUEST_HEADERS. [file
"/etc/httpd/modsecurity.d/blacklisting.conf"] [line "9"] [id "960020"]
[msg "Request Missing a User-Agent Header"] [severity "WARNING"] [uri
"/"] [unique_id "EKtwtgoBPEEAAGSlOEoAAAA4"]

but if they do, you get

ModSecurity: Access denied with code 404 (phase 2). Operator EQ matched
0 at REQUEST_HEADERS. [file
"/etc/httpd/modsecurity.d/blacklisting.conf"] [line "9"] [id "960020"]
[msg "Request Missing a User-Agent Header"] [severity "WARNING"]
[hostname "ip.address"] [uri "/"] [unique_id "Eeo7MwoBPEEAAGShN0UAAAA0"]

Compile ModSecurity with Nginx according to the document, download the rule package modsecurity-apache_2.7.4.tar.gz, then concatenating the following files into the modsecurity.conf file:
modsecurity.conf-recommended
modsecurity_crs_10_setup.conf
OWASP ModSecurity CRS base_rules conf files
add the following directive to nginx configure file:
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;
copy base_rules/*.data files into the conf directory in nginx.
Configure nginx, add a backend server for it, then start nginx, then reload nginx by 'nginx -s reload', and access the backend server though nginx, failed! See the error.log of nginx, can find nginx worker has died:

3196 2013/06/17 15:22:49 [debug] 6445#0: 1 add cleanup: 0000000001CDD5D8
3197 2013/06/17 15:22:49 [debug] 6445#0: *1 posix_memalign: 0000000001CDD6D0:4096 @16
3198 2013/06/17 15:22:49 [debug] 6445#0: *1 add cleanup: 0000000001CDD628
3199 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Host: 10.5.1.22"
3200 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0"
3201 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/*;q=0.8"
3202 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3"
3203 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Accept-Encoding: gzip, deflate"
3204 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Referer: http://10.5.1.22/"
3205 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Connection: keep-alive"
3206 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in: "Cache-Control: max-age=0"
3207 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: load headers in done
3208 2013/06/17 15:22:49 [error] 6445#0: [client 10.5.1.22] ModSecurity: Rule processing failed. [hostname "jason"] [uri "/info.php"] [unique_id "Ackc@ cAcZcA5AclsAcAcAcAZA"]
3209 2013/06/17 15:22:49 [error] 6445#0: [client 10.5.1.22] ModSecurity: Rule processing failed. [hostname "jason"] [uri "/info.php"] [unique_id "Ackc@ cAcZcA5AclsAcAcAcAZA"]
3210 2013/06/17 15:22:49 [error] 6445#0: [client 10.5.1.22] ModSecurity: Rule processing failed. [hostname "jason"] [uri "/info.php"] [unique_id "Ackc@ cAcZcA5AclsAcAcAcAZA"]
3211 2013/06/17 15:22:49 [error] 6445#0: [client 10.5.1.22] ModSecurity: Rule processing failed. [hostname "jason"] [uri "/info.php"] [unique_id "Ackc@ cAcZcA5AclsAcAcAcAZA"]
3212 2013/06/17 15:22:49 [error] 6445#0: [client 10.5.1.22] ModSecurity: Rule processing failed. [hostname "jason"] [uri "/info.php"] [unique_id "Ackc@ cAcZcA5AclsAcAcAcAZA"]
3213 2013/06/17 15:22:49 [error] 6445#0: [client 10.5.1.22] ModSecurity: Rule processing failed. [hostname "jason"] [uri "/info.php"] [unique_id "Ackc@ cAcZcA5AclsAcAcAcAZA"]
3214 2013/06/17 15:22:49 [debug] 6445#0: *1 ModSecurity: status -1
3215 2013/06/17 15:22:49 [notice] 6441#0: signal 17 (SIGCHLD) received
3216 2013/06/17 15:22:49 [alert] 6441#0: worker process 6445 exited on signal 11 (core dumped)

Files that contais .cookie in the name are being blocked under apache servers.

Files like jquery.cookie.js, a javascript file I understand that needs to be allowed, but not ones that ENDS with .cookie. I think that is just a little asjustement in the regex that calculates the threats.

Thanks.

"ModSecuricy" at:

--enable-request-early - On ModSecuricy 2.6 phase one has been moved to phase 2 hook, if you want to play around it use this option.

MODSEC-12: When an operator execution fails (ie returns <0), the rule is just dropped and fails open (no interception performed).

Example debug output:
{noformat}
[4] Rule returned -1.
[1] Rule processing failed.
{noformat}

This change was introduced in 2.1.2 and may have been a bad decision on my part.

Is this really what we want now? I think it should be an option (maybe SecInterceptOnError On|Off). It should at least be documented.

Version 2.7.1 produces a shell error trying to execute "cut" due to incorrectly nested quotes introduced in commit 0757a9f.

Problematic line inbuild/find_pcre.m4 is:

PCRE_LD_PATH="/${PCRE_CONFIG} --libs | cut -d"/" -f2,3,4,5,6 | cut -d " " -f1"

Correct would be:

PCRE_LD_PATH="/${PCRE_CONFIG} --libs | cut -d'/' -f2,3,4,5,6 | cut -d ' ' -f1"

(Change from >"< to >'< when quoting the cut delimiters.

Otherwise the quotes around the single space are actually terminating the backquote and the shell tries to execute the command "-f1".

MODSEC-5: A missing and/or bad end tag may cause the XML to not be well formed, but it may still pass validation. It seems that libxml2 is being lax here and inserting the correct end tag into the tree?

* Can this lead to an evasion?
* Can (should) we tell libxml2 to be more strict? 

In the following, the XML parsing yields:

{noformat}
XML: Parsing complete (well_formed 0).
XML parser error: XML: Failed parsing document.
...
XML: Successfully validated payload against DTD: /path/to/SoapEnvelope.dtd
{noformat}

XML (missing 'e' in ):
{noformat}

DTD:
{noformat}

{noformat}

Rules:
{noformat}
SecRule REQUEST_HEADERS:Content-Type "^text/xml$"
"phase:1,t:none,t:lowercase,nolog,pass,ctl:requestBodyProcessor=XML"
SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skipAfter:12345
SecRule XML "@validateDTD /path/to/SoapEnvelope.dtd"
"phase:2,deny,id:12345"
{noformat}

Details posted in the following gist

https://gist.github.com/4367282

MODSEC-9: Some off the top of my head:

• drop action
• SecChrootDir
• SecUploadFileMode

I've just installed and configured mod_security 2.7.3 on apache 2.2.15, CentOS 6.3. Everything is started and worked fine, excluding SecPdfProtect directive.
I had no problems protecting pdfs in this way in older versions of mod_security, but with this latest version apache always reports on startup:

"Syntax error on line xx of modescurity_xx_xx.conf. Invalid command 'SecPdfProtect', perhaps misspelled or defined by a module not included in the server configuration."

There are all needed libraries and dependences installed, and I don't understand what causes this problem.

Any help will be appreciate.
Thanks

MODSEC-8: Need to integrate mlogc into ModSecurity codebase. Mlogc should share the same version as ModSecurity itself and be tighter integrated into the configure/make process.

Trying to use 2.7.5 with nginx 1.4.1 on CentOS 6.4 and i am using the recommended modecurity.conf that was part of the source files.

nginx is setup as a reverse caching proxy to tomcat 7.0.42 and it is setup for SSL using openssl 1.0.1e.

When modsecurity is enabled and a request for the site nginx is the proxy for is made, everything is ok, but when using a form submission such as the site's sign in page and either an incorrect or correct login is submitted the system nginx/modsecurity is running on immediately starts to swap and the CPU load increases. The site never responds to the request and eventually times out.

Setting SecResponseBodyAccess to Off eliminates the issue.

MODSEC-16: The issue has been reported on the mailing list. I've also run into it on the tomcat-users mailing list:
http://mail-archives.apache.org/mod_mbox/tomcat-users/200809.mbox/%[email protected]%3E

After having looked at a single audit log entry, it would seem that the response did not contain the WWW-Authenticate header, which is required for Basic Authentication to be triggered.

Hi,

I found pretty disturbing issue in current trunk.
I am using:
nginx version: ngx_openresty/1.4.2.9
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
ModSecurity was build from this commit: 88ebf8a
with this nginx/modsecurity/config file:

ngx_addon_name=ngx_http_modsecurity
CORE_MODULES="$CORE_MODULES ngx_pool_context_module"
HTTP_AUX_FILTER_MODULES="ngx_http_modsecurity $HTTP_AUX_FILTER_MODULES"
NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_modsecurity.c $ngx_addon_dir/apr_bucket_nginx.c $ngx_addon_dir/ngx_pool_context.c"
NGX_ADDON_DEPS="$NGX_ADDON_DEPS $ngx_addon_dir/apr_bucket_nginx.h $ngx_addon_dir/ngx_pool_context.h $ngx_addon_dir/ngx_http_modsecurity.c $ngx_addon_dir/apr_bucket_nginx.c $ngx_addon_dir/ngx_pool_context.c "
CORE_LIBS="$CORE_LIBS $ngx_addon_dir/../../standalone/.libs/standalone.a -L/usr/lib -lapr-1  -L/usr/lib -laprutil-1 -L/usr/lib/x86_64-linux-gnu -lpcre -L/usr/lib/x86_64-linux-gnu -lxml2 -llua5.1   "
CORE_INCS="$CORE_INCS $ngx_addon_dir $ngx_addon_dir/../../standalone $ngx_addon_dir/../../apache2 /usr/include/libxml2 -DWITH_LUA/usr/include/lua5.1   /usr/include/httpd /usr/include/apr-1 /usr/include/apr-1"

This is my minimalistic nginx.conf:

user www-data www-data;
worker_processes 1;
worker_rlimit_nofile 200000;

error_log /var/log/nginx/error.log;

events {
    worker_connections  16384;
    multi_accept on;
    use epoll;
}

http {
    include         /etc/nginx/mime.types;
    default_type    application/octet-stream;

    proxy_http_version 1.1;
    server {
        listen      127.0.0.1:80;

        location / {
            ModSecurityEnabled on;
            ModSecurityConfig modsecurity.conf;
                content_by_lua 'ngx.exit(555)';
        }
    }
}

And minimalistic modsecurity.conf:

SecRuleEngine   On
SecDefaultAction "phase:1,deny,log,status:501"


SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "(?i:(?:(?:s(?:t(?:d(?:dev(_pop|_samp)?)?|r(?:_to_date|cmp))|u(?:b(?:str(?:ing(_index)?)?|(?:dat|tim)e)|m)|e(?:c(?:_to_time|ond)|ssion_user)|ys(?:tem_user|date)|ha(1|2)?|oundex|chema|ig?n|pace|qrt)|i(?:s(null|_(free_lock|ipv4_compat|ipv4_mapped|ipv4|ipv6|not_null|not|null|used_lock))?|n(?:et6?_(aton|ntoa)|s(?:ert|tr)|terval)?|f(null)?)|u(?:n(?:compress(?:ed_length)?|ix_timestamp|hex)|tc_(date|time|timestamp)|p(?:datexml|per)|uid(_short)?|case|ser)|l(?:o(?:ca(?:l(timestamp)?|te)|g(2|10)?|ad_file|wer)|ast(_day|_insert_id)?|e(?:(?:as|f)t|ngth)|case|trim|pad|n)|t(?:ime(stamp|stampadd|stampdiff|diff|_format|_to_sec)?|o_(base64|days|seconds|n?char)|r(?:uncate|im)|an)|m(?:a(?:ke(?:_set|date)|ster_pos_wait|x)|i(?:(?:crosecon)?d|n(?:ute)?)|o(?:nth(name)?|d)|d5)|r(?:e(?:p(?:lace|eat)|lease_lock|verse)|o(?:w_count|und)|a(?:dians|nd)|ight|trim|pad)|f(?:i(?:eld(_in_set)?|nd_in_set)|rom_(base64|days|unixtime)|o(?:und_rows|rmat)|loor)|a(?:es_(?:de|en)crypt|s(?:cii(str)?|in)|dd(?:dat|tim)e|(?:co|b)s|tan2?|vg)|p(?:o(?:sition|w(er)?)|eriod_(add|diff)|rocedure_analyse|assword|i)|b(?:i(?:t_(?:length|count|x?or|and)|n(_to_num)?)|enchmark)|e(?:x(?:p(?:ort_set)?|tract(value)?)|nc(?:rypt|ode)|lt)|v(?:a(?:r(?:_(?:sam|po)p|iance)|lues)|ersion)|g(?:r(?:oup_conca|eates)t|et_(format|lock))|o(?:(?:ld_passwo)?rd|ct(et_length)?)|we(?:ek(day|ofyear)?|ight_string)|n(?:o(?:t_in|w)|ame_const|ullif)|(rawton?)?hex(toraw)?|qu(?:arter|ote)|(pg_)?sleep|year(week)?|d?count|xmltype|hour)\W*\(|\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:sqlexec|sp_replwritetovarbin|sp_help|addextendedproc|is_srvrolemember|prepare|sp_password|execute(?:sql)?|makewebtask|oacreate)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|terminate|xp_servicecontrol|xp_ntsec_enumdomains|xp_terminate_process|e(?:xecresultset|numdsn)|availablemedia|loginconfig|cmdshell|filelist|dirtree|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|d(?:b(?:a_users|ms_java)|elete\b\W*?\bfrom)|group\b.*\bby\b.{1,100}?\bhaving|open(?:rowset|owa_util|query)|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|print\b\W*?\@\@|cast\b\W*?\()|c(?:(?:ur(?:rent_(?:time(?:stamp)?|date|user)|(?:dat|tim)e)|h(?:ar(?:(?:acter)?_length|set)?|r)|iel(?:ing)?|ast|r32)\W*\(|o(?:(?:n(?:v(?:ert(?:_tz)?)?|cat(?:_ws)?|nection_id)|(?:mpres)?s|ercibility|alesce|t)\W*\(|llation\W*\(a))|d(?:(?:a(?:t(?:e(?:(_(add|format|sub))?|diff)|abase)|y(name|ofmonth|ofweek|ofyear)?)|e(?:(?:s_(de|en)cryp|faul)t|grees|code)|ump)\W*\(|bms_\w+\.\b)|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|\butl_inaddr\b|\bsys_context\b|'(?:s(?:qloledb|a)|msdasql|dbo)'))" \
    "phase:2,rev:'2',ver:'OWASP_CRS/2.2.6',maturity:'9',accuracy:'8',capture,t:none,t:urlDecodeUni,ctl:auditLogParts=+E,block,msg:'SQL Injection Attack',id:'950001',tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1',tag:'PCI/6.5.2',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

This is one liner test script to reproduce the issue:

(DEPLOY)root@de03:~/ModSecurity# /etc/init.d/nginx restart && sleep 1 && curl -sL -w "%{http_code}" 'http://127.0.0.1/[email protected];CAST%28current_user;current_database--' -o /dev/null && echo && /etc/init.d/nginx reload  && sleep 1 && curl -sL -w "%{http_code}" 'http://127.0.0.1/[email protected];CAST%28current_user;current_database--' -o /dev/null && echo
Restarting nginx: nginx.
501
Reloading nginx configuration: nginx.
555

I suppose the problem is connected with issue #137 (and suggested patch #139). I was experiencing the same problems when I tried to patch official mod_security 2.7.5 package with suggested patch.

If you need any information I will be happy to provide it.

Confirmed this behaviour on multiple versions of Nginx and Mod-Security for Nginx (including 1.5.1 and trunk).
Have tested with various mod-security configs, including last test which was an empty config file, but same problem occurs.
With debug enabled on nginx and mod-security we see the following happening :

2013/10/14 09:13:34 [debug] 2149#0: 1291 http proxy status 302 "302
Found"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header: "Date: Mon,
14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header: "Server:
Apache"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header: "Expires:
Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Cache-Control: private, no-cache, no-store, proxy-revalidate,
no-transform"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header: "Pragma:
no-cache"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Last-Modified: Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"X-DNS-Prefetch-Control: off"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Set-Cookie: roundcube_sessauth=-del-; expires=Mon, 14-Oct-2013 08:12:34
GMT; path=/; httponly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 posix_memalign:
0000000000A80030:4096 @16
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Set-Cookie: roundcube_sessid=af3b9qt9q15udtlu9pv7jl00p1; path=/;
HttpOnly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Set-Cookie:
roundcube_sessauth=Sa7b59ef7ce29d8007020e51346ac635aa47b0262; path=/;
httponly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header: "Location:
./?task=mail"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header: "Vary:
Accept-Encoding"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Content-Encoding: gzip"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Content-Length: 20"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Connection: close"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header:
"Content-Type: text/html"
2013/10/14 09:13:34 [debug] 2149#0: *1291 http proxy header done
2013/10/14 09:13:34 [debug] 2149#0: *1291 modSecurity: header filter
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Host: REDACTED"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Accept-Language: en-gb,en;q=0.5"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Accept-Encoding: gzip, deflate"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Referer: http://REDACTED/?_task=mail"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Cookie: mailviewsplitterv=165; mailviewsplitter=433;
composesplitterv1=200; composesplitterv2=741; folderviewsplitter=30
0; composesplitterv=248; prefviewsplitter=266;
roundcube_sessid=but5tqa53t1eka2ro3ufsco5d2;
roundcube_sessauth=S901dd25720a42e648834de4db836db0d7996bb52"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Connection: keep-alive"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Content-Type: application/x-www-form-urlencoded"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in:
"Content-Length: 149"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers in
done
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Expires: Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Cache-Control: private, no-cache, no-store, proxy-revalidate,
no-transform"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Pragma: no-cache"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Last-Modified: Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"X-DNS-Prefetch-Control: off"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Set-Cookie: roundcube_sessauth=-del-; expires=Mon, 14-Oct-2013 08:12:34
GMT; path=/; httponly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Set-Cookie: roundcube_sessid=af3b9qt9q15udtlu9pv7jl00p1; path=/;
HttpOnly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Set-Cookie:
roundcube_sessauth=Sa7b59ef7ce29d8007020e51346ac635aa47b0262; path=/;
httponly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Location: ./?_task=mail"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Vary: Accept-Encoding"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Content-Encoding: gzip"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Content-Type: text/html"
2013/10/14 09:13:34 [debug] 2149#0: *1291 posix_memalign:
0000000000A6F140:4096 @16
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Content-Length: 20"
2013/10/14 09:13:34 [debug] 2149#0: 1291 ModSecurity: load headers out:
"Location: ./?task=mail"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Last-Modified: Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Connection: keep-alive"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out:
"Cache-Control: private, no-cache, no-store, proxy-revalidate,
no-transform"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: load headers out
done
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: status -1
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Host: REDACTED"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Accept-Language: en-gb,en;q=0.5"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Accept-Encoding: gzip, deflate"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Referer: http://REDACTED/?_task=mail"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Cookie: mailviewsplitterv=165; mailviewsplitter=433;
composesplitterv1=200; composesplitterv2=741; folderviewsplitter=30
0; composesplitterv=248; prefviewsplitter=266;
roundcube_sessid=but5tqa53t1eka2ro3ufsco5d2;
roundcube_sessauth=S901dd25720a42e648834de4db836db0d7996bb52"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Connection: keep-alive"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Content-Type: application/x-www-form-urlencoded"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in:
"Content-Length: 149"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers in
done
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Expires: Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Cache-Control: private, no-cache, no-store, proxy-revalidate,
no-transform"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Pragma: no-cache"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Last-Modified: Mon, 14 Oct 2013 08:13:34 GMT"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"X-DNS-Prefetch-Control: off"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Set-Cookie:
roundcube_sessauth=Sa7b59ef7ce29d8007020e51346ac635aa47b0262; path=/;
httponly"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Location: ./?_task=mail"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Vary: Accept-Encoding"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Content-Encoding: gzip"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Content-Type: text/html"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Content-Length: 20"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out:
"Connection: keep-alive"
2013/10/14 09:13:34 [debug] 2149#0: *1291 ModSecurity: save headers out
done
2013/10/14 09:13:34 [debug] 2149#0: *1291 HTTP/1.1 302 Found
Server: nginx
Date: Mon, 14 Oct 2013 08:13:34 GMT
Content-Type: text/html
Content-Length: 20
Connection: keep-alive
Expires: Mon, 14 Oct 2013 08:13:34 GMT
Cache-Control: private, no-cache, no-store, proxy-revalidate,
no-transform
Last-Modified: Mon, 14 Oct 2013 08:13:34 GMT
Set-Cookie:
roundcube_sessauth=Sa7b59ef7ce29d8007020e51346ac635aa47b0262; path=/;
httponly
Location: ./?_task=mail
Content-Encoding: gzip

I'm reading this as Apache (my upstream proxy) passing the correct headers down to Nginx, Nginx is passing them to Mod-Security, which is returning them with only one Set-Cookie, but I have no rules that would do this and Mod-Security does not log any actions. If I leave Mod-Security compiled in but not enabled I get the correct functionality and all my cookies

I've also found the same issue described on stackoverflow : http://stackoverflow.com/questions/19059610/mod-security-allowing-only-one-set-cookie .

Paul.

MODSEC-7: When there are errors parsing/validating a schema or DTD, the errors from libxml2 are not logged. This makes issues very hard (perhaps impossible) to diagnose.

Typing this off the top of my head :), so mind any typos.

IIS function HRESULT CMyHttpModule::ReadFileChunk(HTTP_DATA_CHUNK *chunk, char *buf)
fails in the following cases:

• If the datachunk has an offset it will copy the first bytes of the block read instead of the bytes after the offset. This is behaviour seen in ARR, the cache will store headers and content in one file.
  Fix:
  memcpy(buf, pIoBuffer, bytesRead);
  to
  memcpy(buf, pIoBuffer+dwDataStartOffset, bytesRead);
• Bytestotal is not honored in byte ranges, files with a byte range ending before EOF will copy to a whole page extra in buf, possibly overwriting other data (small risk if buf is allocated with a multiple of pagesize) bytesRead should be adjusted before the memcpy to stop it from copying the extra bytes.
  The guarding statement checking bytesRead against the length will not work with multiple page reads.
  Fix:
  if (bytesRead > chunk->FromFileHandle.ByteRange.Length.QuadPart) { bytesRead = (DWORD)chunk->FromFileHandle.ByteRange.Length.QuadPart; }
  if ((bytesTotal+bytesRead) > chunk->FromFileHandle.ByteRange.Length.QuadPart) { bytesRead = chunk->FromFileHandle.ByteRange.Length.QuadPart-bytesTotal; }
• Allocation of the page is implicit, explicitly specifying the pagesize will make the code more robust.

Regards,
Kees

MODSEC-4: Currently you cannot turn off the request body size check via ctl as it is done prior to phase 1 when C-L header is used. This should be moved after phase 1 so users have the option of turning it off for a given URI and/or modifying how the data is audited (ie remove the request body if it might be huge).

MODSEC-17: In order to block 100% reliably we need to buffer; there's no question about that. However, buffering is not always the best, or even desired, approach. Some mechanisms (such as file upload progress bars) rely on having a free flow of data, and there also may be latency issues with very large request and response sizes. Furthermore, turning buffering off when in DetectionOnly mode will make ModSecurity more transparent and reduce memory consumption. This ticket outlines a proposal how to improve on our current handling on content inspection in this respect:

1. Add SecRequestBodyBuffering, which can have two settings: On and Off. Have it On by default to preserve backward compatibility.
2. Also add ctl:requestBodyBuffering, to allow rules to inspect request/response headers and make a decision whether to buffer.
3. On the inbound, do not read request bodies in the fixups phase. Instead, install a different input filter that will be invoked as content becomes available.
4. Add SecResponseBodyBuffering, with two settings: On and Off. Have it On by default.
5. Add ctl:responseBodyBuffering.
6. On the outbound, since the current filter is content driven already I think it can be modified to support operation without buffering.
7. Do not block in phases 2 (request buffering disabled) and phase 4 (response buffering disabled).
8. Automatically disable buffering in DetectionOnly mode.
9. Implement a streaming urlencoded parser.
10. Determine when to populate REQUEST_BODY, and how to allow users to control that feature (and if to allow them to control it at all).

I have a recently installed reverse proxy deployed WAF installed running 2.7.4 using mlogc sending logs to a central AuditConsole server. We use the atomicorp commercial rules, hardware spec is as follows: dual quad core Xeon CPU, 32GB RAM, CentOs 6.4 64-bit.

Today, the web apps being protected by the WAF went down and after looking at the reverse proxy I could see mlogc running at 100% on a single CPU core, after running "ps aux | grep mlogc" I could see 2 instances running. I issued the command "kill 1983" as 1983 was the process utilizing 100%. This did not work, so I issued the command "kill -9 1983" which was successful. I am keeping a very close eye on this now

httpd -v

Server version: Apache/2.2.15 (Unix)
Server built: May 13 2013 22:11:16

/opt/modsecurity/bin/mlogc -v

ModSecurity Log Collector (mlogc) v2.7.4
APR: compiled="1.3.9"; loaded="1.3.9"
PCRE: compiled="7.8"; loaded="7.8 2008-09-05"
cURL: compiled="7.19.7"; loaded="libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2"

Can I provide any further details to help assist? All configuration other than CollectorRoot and LogstorageDir and the sensor credentials are default in mlogc.conf

Thanks,

Craig

MODSEC-13: Needed:

• t:parity7bitEven - Calcs even parity and changes 8th bit of each byte
• t:parity7bitOdd - Calcs odd parity and changes 8th bit of each byte
• t:parity7bitZero - Zeros the 8th bit, removing the parity.

This allows someone to validate parity as well as remove it:

Example of checking even parity:

{noformat}
SecRule TARGET ".*" "capture,pass,nolog,t:none,t:parity7bitEven"
SecRule TARGET "!@Streq %{TX.0}" "deny,msg:'Failed parity check',t:none"
{noformat}

MODSEC-6: REQUEST_BODY is only populated for known parseable types. But sometimes we may need access to this target for content types we know nothing about. Right now, you can set ctl:requestBodyProcessor=URLENCODED and REQUEST_BODY may be used, but there will be warnings/errors parsing the protocol.

There needs to be a way to force buffering the request so that REQUEST_BODY can be used without attempting to parse.

Building the package from the download section (2.7.1) fails with a lua argument error. The details are in the following gist

https://gist.github.com/4367310

The documentation shows, that SecRuleUpdateTargetById can be used in any scope.

The config for my vhost looks like this:

<VirtualHost *:80>
  SecRuleUpdateTargetById 973020 !REQUEST_COOKIES
  ... 
</VirtualHost>

As soon as I restart the Apache with the SecRuleUpdateTargetById inside the virtualhost config, Apache refuses to start and claims the following error message

Updating target by ID with no ruleset in this context

I'm using the latest version of ModSecurity and the OWASP CRS.

Is this a bug, is the documentation wrong or am I missing something?

Windows 2008 R2 x64
ModSecurity IIS 2.7.3

When installed, any application pool set to 'Enable 32-Bit Applications' TRUE will fail to stay running, they will instantly crash after IIS starts up. Removing ModSecurityIIS restores functionality of the app pool/website.