Segmentation Fault in modsecurity_log_cb (Security)

[Devstellar]

Testing ModSecurity3 in Apache I got some httpd cores at random times. Troubleshooting I found this problem.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fa6e8f112ea in apr_vformatter () from /usr/lib64/libapr-1.so.0
[Current thread is 1 (Thread 0x7fa6a97fa640 (LWP 454336))]
(gdb) bt
#0  0x00007fa6e8f112ea in apr_vformatter () from /usr/lib64/libapr-1.so.0
#1  0x00007fa6e8f12e57 in apr_vsnprintf () from /usr/lib64/libapr-1.so.0
#2  0x00000000004636b0 in log_error_core ()
#3  0x0000000000465473 in ap_log_rerror_ ()
#4  0x00007fa6e8727262 in modsecurity_log_cb (log=0x7fa69c085b60, data=0x7fa69016f7a0) at src/mod_security3.c:24
#5  0x00007fa6e85a352f in modsecurity::ModSecurity::serverLog (this=0x242bbb0, data=0x7fa69c085b60, rm=...) at modsecurity.cc:207
#6  0x00007fa6e85925b8 in modsecurity::Transaction::serverLog (this=0x7fa69014f4f0, rm=...) at transaction.cc:1818
#7  0x00007fa6e85b2cfa in modsecurity::RuleWithActions::performLogging (this=0x300aa20, trans=0x7fa69014f4f0, ruleMessage=..., lastLog=true, chainedParentNull=true) at rule_with_actions.cc:505
#8  0x00007fa6e85ba69d in modsecurity::RuleWithOperator::evaluate (this=0x300aa20, trans=0x7fa69014f4f0, ruleMessage=...) at rule_with_operator.cc:372
#9  0x00007fa6e85b07c2 in modsecurity::RuleWithActions::evaluate (this=0x300aa20, transaction=0x7fa69014f4f0) at rule_with_actions.cc:173
#10 0x00007fa6e85a6653 in modsecurity::RulesSet::evaluate (this=0x243b370, phase=3, t=0x7fa69014f4f0) at rules_set.cc:210
#11 0x00007fa6e858a9ca in modsecurity::Transaction::processRequestBody (this=0x7fa69014f4f0) at transaction.cc:942
#12 0x00007fa6e8592813 in modsecurity::msc_process_request_body (transaction=0x7fa69014f4f0) at transaction.cc:1979
#13 0x00007fa6e8726a3d in input_filter (f=0x7fa67c015180, pbbOut=0x7fa67c0151d8, mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, nbytes=8192) at src/msc_filters.c:66
#14 0x000000000047af68 in ap_discard_request_body ()
#15 0x000000000044ae32 in default_handler ()
#16 0x0000000000460065 in ap_invoke_handler ()
#17 0x00000000004775c6 in ap_process_async_request ()
#18 0x0000000000473900 in ap_process_http_connection ()
#19 0x0000000000469d0f in ap_run_process_connection ()
#20 0x00007fa6e8c1d8af in process_socket () from /usr/lib64/httpd/modules/mod_mpm_event.so
#21 0x00007fa6e8c1e3bc in worker_thread () from /usr/lib64/httpd/modules/mod_mpm_event.so
#22 0x00007fa6e8e8ffd6 in start_thread () from /lib64/libpthread.so.0
#23 0x00007fa6e8db01df in clone () from /lib64/libc.so.6

In frame 4, function modsecurity_log_cb, there are these calls to ap_log_rerror and ap_log_error:

    ap_log_rerror(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r,
        msg,
        r->status);

#else
    ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r->server,
        msg,
        r->status);

According to apr documentation these calls are prompt to a Format String Attack, and indeed this is the cause of my coredumps, as "msg" is not sanitized, it can contain % characters.

(gdb) f 4
#4  0x00007fa6e8727262 in modsecurity_log_cb (log=0x7fa69c085b60, data=0x7fa69016f7a0) at src/mod_security3.c:24
24          ap_log_rerror(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r,
(gdb) p msg
$2 = 0x7fa69016f7a0 "ModSecurity: Warning. Matched \"Operator `Rx' with parameter `(?:unmarshaller|base64data|java\\.)' against variable `REQUEST_BODY' (Value: `queryString=aaaaaaaa%5Cu0027%2B%7BClass.forName%28%5Cu0027javax.script.ScriptEngineManager%5Cu0027%2 (1046 characters omitted)' ) [file \"/etc/httpd/modsec/coreruleset/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf\"] [line \"65\"] [id \"944110\"] [rev \"\"] [msg \"Remote Command Execution: Java process spawn (CVE-2017-9805)\"] [data \"Matched Data: queryString=aaaaaaaa%5Cu0027%2B%7BClass.forName%28%5Cu0027javax.script.ScriptEngineManager%5Cu0027%29.newInstance%28%29.getEngineByName%28%5Cu0027JavaScript%5Cu0027%29.%5Cu0065val%28%5Cu (986 characters omitted)\"] [severity \"2\"] [ver \"OWASP_CRS/3.3.2\"] [maturity \"0\"] [accuracy \"0\"] [tag \"application-multi\"] [tag \"language-java\"] [tag \"platform-multi\"] [tag \"attack-rce\"] [tag \"OWASP_CRS\"] [tag \"capec/1000/152/248\"] [tag \"PCI/6.5.2\"] [tag \"paranoia-level/1\"] [hostname \"none.none.com\"] [uri \"/pages/createpage-entervariables.action\"] [unique_id \"1631537158\"] [ref \"o382,14v218,900t:lowercaseo478,14v206,1146t:lowercaseo158,5v218,900o204,5v206,1146\"]"

I think the proper calls should be changed to something like this:

    ap_log_rerror(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, 0, r,
        "%s", msg);

[martinhsv]

Hello @Devstellar ,

I just thought I should highlight that no one on the core ModSecurity team has any time allocated to working on ModSecurity-apache.

The ModSecurity version recommended for use with Apache HTTP Server continues to be v2.9.x (https://github.com/SpiderLabs/ModSecurity-apache#note--this-project-is-not-production-ready )

Since ModSecurity-apache is an open-source project in github, you are, of course, free to experiment with it as you choose. But, please just be aware that there is no real prospect of the sponsoring company's staff following up on any issues you may create.