Thread: [mod-security-users] Can't load some base_rules - Apache hangs
Brought to you by:
victorhora,
zimmerletw
From: Steffan V. <sv...@bo...> - 2010-09-02 22:21:09
|
Hello, Having trouble getting mod_security to load the base set of rules. If I start Apache commenting out the base_rules conf files, it starts just fine. > <IfModule security2_module> > Include > /usr/local/apache2/conf/Includes/mod_security2/modsecurity_crs_10_config.conf > # Include > /usr/local/apache2/conf/Includes/mod_security2/base_rules/*.conf > </IfModule> From the Apache log: > [Thu Sep 02 13:16:47 2010] [notice] ModSecurity for Apache/2.5.12 > (http://www.modsecurity.org/) configured. > [Thu Sep 02 13:16:48 2010] [notice] Apache/2.2.16 (Unix) > mod_ssl/2.2.16 OpenSSL/0.9.8n PHP/5.2.14 configured -- resuming normal > operations But if I uncomment that line and try to read in the default ruleset, it just hangs and I have to cntl-c to quit. > <IfModule security2_module> > Include > /usr/local/apache2/conf/Includes/mod_security2/modsecurity_crs_10_config.conf > Include > /usr/local/apache2/conf/Includes/mod_security2/base_rules/*.conf > </IfModule> > > village [/usr/local/apache2/]# apachectl -e debug > [Thu Sep 02 14:17:08 2010] [debug] mod_so.c(328): loaded file > /usr/local/lib/libxml2.so > [Thu Sep 02 14:17:08 2010] [debug] mod_so.c(246): loaded module > php5_module > [Thu Sep 02 14:17:08 2010] [debug] mod_so.c(246): loaded module > security2_module > ^C > > village [/usr/local/apache2/]# > No output in the Apache Error log or the modsec_debug.log, even with debugging turned all the way up. The only way I can get something to output is to build mod_sec with debugging enabled. With that, I can see that it starts to parse the rules before the hang: > village [/usr/local/apache2/]# apachectl -e debug > > [Thu Sep 02 14:02:27 2010] [debug] mod_so.c(328): loaded file > /usr/local/lib/libxml2.so > [Thu Sep 02 14:02:27 2010] [debug] mod_so.c(246): loaded module > php5_module > [Thu Sep 02 14:02:27 2010] [debug] mod_so.c(246): loaded module > security2_module > Created directory config 2855bba0 path (null) > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}' > Adding rule 2909e3d0 phase=1 id="(none)". > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,nolog,pass,setvar:tx.paranoid_mode=0' > Adding rule 2909ed70 phase=1 id="(none)". > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,nolog,pass,setvar:tx.inbound_anomaly_score_level=20' > Adding rule 2909f418 phase=1 id="(none)". > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,nolog,pass,setvar:tx.outbound_anomaly_score_level=15' > Adding rule 2909fb70 phase=1 id="(none)". > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,nolog,pass, setvar:tx.critical_anomaly_score=20, > setvar:tx.error_anomaly_score=15, setvar:tx.warning_anomaly_score=10, > setvar:tx.notice_anomaly_score=5' > Adding rule 290a2350 phase=1 id="(none)". > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,nolog,pass,setvar:tx.max_num_args=255' > Adding rule 290a3180 phase=1 id="(none)". > Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' > p3='phase:1,t:none,nolog,pass, setvar:'tx.allowed_methods=GET HEAD > POST OPTIONS', > setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded > multipart/form-data text/xml application/xml', > setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', > setvar:'tx.restricted_extensions=.asa .asax .ascx .axd .backup .bak > .bat .cdx .cer .cfg .cmd .com .config .conf .cs .csproj .csr .dat .db > .dbf .dll .dos .htr .htw .ida .idc .idq .inc .ini .key .licx .lnk .log > .mdb .old .pass .pdb .pol .printer .pwd .resources .resx .sql .sys .vb > .vbs .vbproj .vsdisco .webinfo .xsd .xsx', > setvar:'tx.restricted_headers=Proxy-Connection Lock-Token > Content-Range Translate via if'' > Adding rule 290a3a98 phase=1 id="(none)". > Rule: type=0 p1='REQUEST_LINE' > p2='!^(?:(?:[a-z]{3,10}\\s+(?:\\w{3,7}?://[\\w\\-\\./]*(?::\\d+)?)?/[^?#]*(?:\\?[^#\\s]*)?(?:#[\\S]*)?|connect > (?:\\d{1,3}\\.){3}\\d{1,3}\\.?(?::\\d+)?|options > \\*)\\s+[\\w\\./]+|get /[^?#]*(?:\\?[^#\\s]*)?(?:#[\\S]*)?)$' > p3='t:none,t:lowercase,phase:2,deny,log,auditlog,status:400,msg:'Invalid > HTTP Request Line',id:'960911',severity:'2'' > > ^C If I hand pick a few conf files, it does load. Those that load are: * modsecurity_crs_35_bad_robots.conf * modsecurity_35_scanners.data * modsecurity_35_bad_robots.data * modsecurity_crs_47_common_exceptions.conf * modsecurity_crs_42_tight_security.conf * modsecurity_42_comment_spam.data * modsecurity_crs_48_local_exceptions.conf * modsecurity_crs_49_inbound_blocking.conf * modsecurity_crs_49_enforcement.conf * modsecurity_crs_59_outbound_blocking.conf * modsecurity_crs_60_correlation.conf Those that won't load are: * modsecurity_crs_20_protocol_violations.conf * modsecurity_crs_21_protocol_anomalies.conf * modsecurity_crs_23_request_limits.conf * modsecurity_crs_30_http_policy.conf * modsecurity_crs_45_trojans.conf * modsecurity_crs_41_xss_attacks.conf * modsecurity_crs_41_phpids_converter.conf * modsecurity_crs_41_phpids_filters.conf * modsecurity_crs_41_sql_injection_attacks.conf I'm at a loss. I'm working on FreeBSD 8.1 and compiling everything from source using the latest versions of httpd (2.2.16) & modsecurity (2.5.12). Configure and make never complain, and I checked that all the mod_sec dependencies are also up to date. I'm not using liblua or libcurl. Could that be the problem? What else could I check? Thanks -Steffan |
From: Rainer J. <rai...@ki...> - 2010-09-04 09:09:08
|
On 03.09.2010 00:05, Steffan Vigano wrote: > Hello, > > Having trouble getting mod_security to load the base set of rules. If > I start Apache commenting out the base_rules conf files, it starts just > fine. > >> <IfModule security2_module> >> Include >> /usr/local/apache2/conf/Includes/mod_security2/modsecurity_crs_10_config.conf >> # Include >> /usr/local/apache2/conf/Includes/mod_security2/base_rules/*.conf >> </IfModule> > > > From the Apache log: > > >> [Thu Sep 02 13:16:47 2010] [notice] ModSecurity for Apache/2.5.12 >> (http://www.modsecurity.org/) configured. >> [Thu Sep 02 13:16:48 2010] [notice] Apache/2.2.16 (Unix) >> mod_ssl/2.2.16 OpenSSL/0.9.8n PHP/5.2.14 configured -- resuming normal >> operations > > > But if I uncomment that line and try to read in the default ruleset, it > just hangs and I have to cntl-c to quit. > > >> <IfModule security2_module> >> Include >> /usr/local/apache2/conf/Includes/mod_security2/modsecurity_crs_10_config.conf >> Include >> /usr/local/apache2/conf/Includes/mod_security2/base_rules/*.conf >> </IfModule> >> >> village [/usr/local/apache2/]# apachectl -e debug >> [Thu Sep 02 14:17:08 2010] [debug] mod_so.c(328): loaded file >> /usr/local/lib/libxml2.so >> [Thu Sep 02 14:17:08 2010] [debug] mod_so.c(246): loaded module >> php5_module >> [Thu Sep 02 14:17:08 2010] [debug] mod_so.c(246): loaded module >> security2_module >> ^C >> >> village [/usr/local/apache2/]# >> > > > No output in the Apache Error log or the modsec_debug.log, even with > debugging turned all the way up. The only way I can get something to > output is to build mod_sec with debugging enabled. With that, I can > see that it starts to parse the rules before the hang: > > >> village [/usr/local/apache2/]# apachectl -e debug >> >> [Thu Sep 02 14:02:27 2010] [debug] mod_so.c(328): loaded file >> /usr/local/lib/libxml2.so >> [Thu Sep 02 14:02:27 2010] [debug] mod_so.c(246): loaded module >> php5_module >> [Thu Sep 02 14:02:27 2010] [debug] mod_so.c(246): loaded module >> security2_module >> Created directory config 2855bba0 path (null) >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}' >> Adding rule 2909e3d0 phase=1 id="(none)". >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,nolog,pass,setvar:tx.paranoid_mode=0' >> Adding rule 2909ed70 phase=1 id="(none)". >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,nolog,pass,setvar:tx.inbound_anomaly_score_level=20' >> Adding rule 2909f418 phase=1 id="(none)". >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,nolog,pass,setvar:tx.outbound_anomaly_score_level=15' >> Adding rule 2909fb70 phase=1 id="(none)". >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,nolog,pass, setvar:tx.critical_anomaly_score=20, >> setvar:tx.error_anomaly_score=15, setvar:tx.warning_anomaly_score=10, >> setvar:tx.notice_anomaly_score=5' >> Adding rule 290a2350 phase=1 id="(none)". >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,nolog,pass,setvar:tx.max_num_args=255' >> Adding rule 290a3180 phase=1 id="(none)". >> Rule: type=1 p1='REMOTE_ADDR' p2='@unconditionalMatch' >> p3='phase:1,t:none,nolog,pass, setvar:'tx.allowed_methods=GET HEAD >> POST OPTIONS', >> setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded >> multipart/form-data text/xml application/xml', >> setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', >> setvar:'tx.restricted_extensions=.asa .asax .ascx .axd .backup .bak >> .bat .cdx .cer .cfg .cmd .com .config .conf .cs .csproj .csr .dat .db >> .dbf .dll .dos .htr .htw .ida .idc .idq .inc .ini .key .licx .lnk .log >> .mdb .old .pass .pdb .pol .printer .pwd .resources .resx .sql .sys .vb >> .vbs .vbproj .vsdisco .webinfo .xsd .xsx', >> setvar:'tx.restricted_headers=Proxy-Connection Lock-Token >> Content-Range Translate via if'' >> Adding rule 290a3a98 phase=1 id="(none)". >> Rule: type=0 p1='REQUEST_LINE' >> p2='!^(?:(?:[a-z]{3,10}\\s+(?:\\w{3,7}?://[\\w\\-\\./]*(?::\\d+)?)?/[^?#]*(?:\\?[^#\\s]*)?(?:#[\\S]*)?|connect >> (?:\\d{1,3}\\.){3}\\d{1,3}\\.?(?::\\d+)?|options >> \\*)\\s+[\\w\\./]+|get /[^?#]*(?:\\?[^#\\s]*)?(?:#[\\S]*)?)$' >> p3='t:none,t:lowercase,phase:2,deny,log,auditlog,status:400,msg:'Invalid >> HTTP Request Line',id:'960911',severity:'2'' >> >> ^C > > > If I hand pick a few conf files, it does load. Those that load are: > > * modsecurity_crs_35_bad_robots.conf > * modsecurity_35_scanners.data > * modsecurity_35_bad_robots.data > * modsecurity_crs_47_common_exceptions.conf > * modsecurity_crs_42_tight_security.conf > * modsecurity_42_comment_spam.data > * modsecurity_crs_48_local_exceptions.conf > * modsecurity_crs_49_inbound_blocking.conf > * modsecurity_crs_49_enforcement.conf > * modsecurity_crs_59_outbound_blocking.conf > * modsecurity_crs_60_correlation.conf > > Those that won't load are: > > * modsecurity_crs_20_protocol_violations.conf > * modsecurity_crs_21_protocol_anomalies.conf > * modsecurity_crs_23_request_limits.conf > * modsecurity_crs_30_http_policy.conf > * modsecurity_crs_45_trojans.conf > * modsecurity_crs_41_xss_attacks.conf > * modsecurity_crs_41_phpids_converter.conf > * modsecurity_crs_41_phpids_filters.conf > * modsecurity_crs_41_sql_injection_attacks.conf > > > I'm at a loss. I'm working on FreeBSD 8.1 and compiling everything > from source using the latest versions of httpd (2.2.16)& modsecurity > (2.5.12). Configure and make never complain, and I checked that all > the mod_sec dependencies are also up to date. I'm not using liblua or > libcurl. Could that be the problem? What else could I check? > > Thanks > -Steffan Is the process consuming CPU during the hang? Can you check the code stack when it hangs using e.g. gstack or gdb or something similar for FreeBSD? Regards, Rainer |
From: Steffan V. <sv...@bo...> - 2010-09-06 19:16:42
|
On 9/4/2010 1:50 AM, Rainer Jung wrote: > Is the process consuming CPU during the hang? Can you check the code > stack when it hangs using e.g. gstack or gdb or something similar for > FreeBSD? Thanks for the reply. Yes, the httpd process does climbs to 100% during the hang. Here's a backtrace of the hung process. Hopefully that's what you're looking for. -S > village [/]# gdb -p 54286 /usr/local/apache2/bin/httpd > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd"... > Attaching to program: /usr/local/apache2/bin/httpd, process 54286 > Reading symbols from /lib/libz.so.5...done. > Loaded symbols for /lib/libz.so.5 > Reading symbols from /usr/local/lib/libldap-2.3.so.2...done. > Loaded symbols for /usr/local/lib/libldap-2.3.so.2 > Reading symbols from /usr/local/lib/liblber-2.3.so.2...done. > Loaded symbols for /usr/local/lib/liblber-2.3.so.2 > Reading symbols from /usr/lib/libssl.so.6...done. > Loaded symbols for /usr/lib/libssl.so.6 > Reading symbols from /lib/libcrypto.so.6...done. > Loaded symbols for /lib/libcrypto.so.6 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/local/apache2/lib/libaprutil-1.so.3...done. > Loaded symbols for /usr/local/apache2/lib/libaprutil-1.so.3 > Reading symbols from /usr/local/lib/libexpat.so.6...done. > Loaded symbols for /usr/local/lib/libexpat.so.6 > Reading symbols from /usr/local/apache2/lib/libapr-1.so.4...done. > Loaded symbols for /usr/local/apache2/lib/libapr-1.so.4 > Reading symbols from /lib/libcrypt.so.5...done. > Loaded symbols for /lib/libcrypt.so.5 > Reading symbols from /lib/libthr.so.3...done. > [New Thread 28501140 (LWP 100077)] > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/local/lib/libxml2.so...done. > Loaded symbols for /usr/local/lib/libxml2.so > Reading symbols from /usr/local/lib/libiconv.so.3...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /usr/local/apache2/modules/libphp5.so...done. > Loaded symbols for /usr/local/apache2/modules/libphp5.so > Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.16...done. > Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.16 > Reading symbols from /usr/local/lib/libpng.so.6...done. > Loaded symbols for /usr/local/lib/libpng.so.6 > Reading symbols from > /usr/local/apache2/modules/mod_security2_debug.so...done. > Loaded symbols for /usr/local/apache2/modules/mod_security2_debug.so > Reading symbols from /usr/local/lib/libpcre.so.0...done. > Loaded symbols for /usr/local/lib/libpcre.so.0 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > [Switching to Thread 28501140 (LWP 100077)] > 0x28f750db in find_minlength () from /usr/local/lib/libpcre.so.0 > (gdb) > (gdb) bt > #0 0x28f750db in find_minlength () from /usr/local/lib/libpcre.so.0 > #1 0x28f7565e in pcre_study () from /usr/local/lib/libpcre.so.0 > #2 0x28f1d613 in msc_pregcomp_ex (pool=0xbfbfe398, pattern=0x29054d80 > "\\bsys\\.user_catalog\\b", options=36, _errptr=0xbfbfe418, > _erroffset=0xbfbfe414, match_limit=0, match_limit_recursion=0) at > msc_pcre.c:69 > #3 0x28f34974 in msre_op_rx_param_init (rule=0x29054f80, > error_msg=0xbfbfe478) at re_operators.c:87 > #4 0x28f3a948 in msre_rule_create (ruleset=0x29010980, type=0, > fn=0x2859b030 > "/usr/local/apache2/conf/Includes/mod_security2/TEMP/modsecurity_crs_41_sql_injection_attacks.conf", > line=40, > targets=0x29054d50 "REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*", > args=0x29054d80 "\\bsys\\.user_catalog\\b", > actions=0x29054d98 > "phase:2,rev:'2.0.5',capture,t:none,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Blind > SQL Injection > Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'"..., > error_msg=0xbfbfe4d8) > at re.c:1535 > #5 0x28f3e697 in add_rule (cmd=0xbfbfe680, dcfg=0x28562ae0, type=0, > p1=0x29054d50 "REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*", > p2=0x29054d80 "\\bsys\\.user_catalog\\b", > p3=0x29054d98 > "phase:2,rev:'2.0.5',capture,t:none,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Blind > SQL Injection > Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'"...) > at apache2_config.c:608 > #6 0x0807e682 in invoke_cmd (cmd=0x28f50478, parms=0xbfbfe680, > mconfig=0x28562ae0, args=0x2859b660 "") at config.c:857 > #7 0x0807ec60 in ap_walk_config (current=0x2859b418, > parms=0xbfbfe680, section_vector=0x28555ca8) at config.c:1163 > #8 0x0807ed97 in ap_process_config_tree (s=0x2851a228, > conftree=0x2855d120, p=0x2850f018, ptemp=0x28553018) at config.c:1765 > #9 0x0806ab81 in main (argc=676384792, argv=0x2850f018) at main.c:644 > (gdb) |
From: Brian R. <bre...@gm...> - 2010-09-06 19:41:13
|
Looks like it is compiling a regex. Note the regex in frame 2. Does it always hng at that one? You can also try building without pcre studying. This is an option to configure, but i cannot rember it right now (./configure --help) -B On Sep 6, 2010 12:21 PM, "Steffan Vigano" <sv...@bo...> wrote: On 9/4/2010 1:50 AM, Rainer Jung wrote: > Is the process consuming CPU during the hang? Can you che... Thanks for the reply. Yes, the httpd process does climbs to 100% during the hang. Here's a backtrace of the hung process. Hopefully that's what you're looking for. -S > village [/]# gdb -p 54286 /usr/local/apache2/bin/httpd > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd"... > Attaching to program: /usr/local/apache2/bin/httpd, process 54286 > Reading symbols from /lib/libz.so.5...done. > Loaded symbols for /lib/libz.so.5 > Reading symbols from /usr/local/lib/libldap-2.3.so.2...done. > Loaded symbols for /usr/local/lib/libldap-2.3.so.2 > Reading symbols from /usr/local/lib/liblber-2.3.so.2...done. > Loaded symbols for /usr/local/lib/liblber-2.3.so.2 > Reading symbols from /usr/lib/libssl.so.6...done. > Loaded symbols for /usr/lib/libssl.so.6 > Reading symbols from /lib/libcrypto.so.6...done. > Loaded symbols for /lib/libcrypto.so.6 > Reading symbols from /lib/libm.so.5...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/local/apache2/lib/libaprutil-1.so.3...done. > Loaded symbols for /usr/local/apache2/lib/libaprutil-1.so.3 > Reading symbols from /usr/local/lib/libexpat.so.6...done. > Loaded symbols for /usr/local/lib/libexpat.so.6 > Reading symbols from /usr/local/apache2/lib/libapr-1.so.4...done. > Loaded symbols for /usr/local/apache2/lib/libapr-1.so.4 > Reading symbols from /lib/libcrypt.so.5...done. > Loaded symbols for /lib/libcrypt.so.5 > Reading symbols from /lib/libthr.so.3...done. > [New Thread 28501140 (LWP 100077)] > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /lib/libc.so.7...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /usr/local/lib/libxml2.so...done. > Loaded symbols for /usr/local/lib/libxml2.so > Reading symbols from /usr/local/lib/libiconv.so.3...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /usr/local/apache2/modules/libphp5.so...done. > Loaded symbols for /usr/local/apache2/modules/libphp5.so > Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.16...done. > Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.16 > Reading symbols from /usr/local/lib/libpng.so.6...done. > Loaded symbols for /usr/local/lib/libpng.so.6 > Reading symbols from > /usr/local/apache2/modules/mod_security2_debug.so...done. > Loaded symbols for /usr/local/apache2/modules/mod_security2_debug.so > Reading symbols from /usr/local/lib/libpcre.so.0...done. > Loaded symbols for /usr/local/lib/libpcre.so.0 > Reading symbols from /libexec/ld-elf.so.1...done. > Loaded symbols for /libexec/ld-elf.so.1 > [Switching to Thread 28501140 (LWP 100077)] > 0x28f750db in find_minlength () from /usr/local/lib/libpcre.so.0 > (gdb) > (gdb) bt > #0 0x28f750db in find_minlength () from /usr/local/lib/libpcre.so.0 > #1 0x28f7565e in pcre_study () from /usr/local/lib/libpcre.so.0 > #2 0x28f1d613 in msc_pregcomp_ex (pool=0xbfbfe398, pattern=0x29054d80 > "\\bsys\\.user_catalog\\b", options=36, _errptr=0xbfbfe418, > _erroffset=0xbfbfe414, match_limit=0, match_limit_recursion=0) at > msc_pcre.c:69 > #3 0x28f34974 in msre_op_rx_param_init (rule=0x29054f80, > error_msg=0xbfbfe478) at re_operators.c:87 > #4 0x28f3a948 in msre_rule_create (ruleset=0x29010980, type=0, > fn=0x2859b030 > "/usr/local/apache2/conf/Includes/mod_security2/TEMP/modsecurity_crs_41_sql_injection_attacks.conf", > line=40, > targets=0x29054d50 "REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*", > args=0x29054d80 "\\bsys\\.user_catalog\\b", > actions=0x29054d98 > "phase:2,rev:'2.0.5',capture,t:none,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Blind > SQL Injection > Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'"..., > error_msg=0xbfbfe4d8) > at re.c:1535 > #5 0x28f3e697 in add_rule (cmd=0xbfbfe680, dcfg=0x28562ae0, type=0, > p1=0x29054d50 "REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*", > p2=0x29054d80 "\\bsys\\.user_catalog\\b", > p3=0x29054d98 > "phase:2,rev:'2.0.5',capture,t:none,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Blind > SQL Injection > Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'"...) > at apache2_config.c:608 > #6 0x0807e682 in invoke_cmd (cmd=0x28f50478, parms=0xbfbfe680, > mconfig=0x28562ae0, args=0x2859b660 "") at config.c:857 > #7 0x0807ec60 in ap_walk_config (current=0x2859b418, > parms=0xbfbfe680, section_vector=0x28555ca8) at config.c:1163 > #8 0x0807ed97 in ap_process_config_tree (s=0x2851a228, > conftree=0x2855d120, p=0x2850f018, ptemp=0x28553018) at config.c:1765 > #9 0x0806ab81 in main (argc=676384792, argv=0x2850f018) at main.c:644 > (gdb) ------------------------------------------------------------------------------ This SF.net Dev2... |
From: Steffan V. <sv...@bo...> - 2010-09-06 20:26:54
|
On 9/6/2010 12:41 PM, Brian Rectanus wrote: > > Looks like it is compiling a regex. Note the regex in frame 2. Does it > always hng at that one?You can also try building without pcre > studying. This is an option to configure, but i cannot rember it right > now (./configure --help) > It always seems to hangs there. As I shuffle some of the base rules in or out of the include directory, the lower portions of the back trace are different but the upper few sections are always the same. Playing with the configure option '--disable-pcre-study' (or --enable-pcre-study=no) unfortunately did not do anything. Even with it disabled, it still shows as frame #2. I uninstalled and reinstalled the latest PCRE but it didn't change. See below for a bt with that option off and it hanging while parsing a different rule. Thanks -S > #0 0x28f67425 in find_minlength () from /usr/local/lib/libpcre.so.0 > #1 0x28f6790e in pcre_study () from /usr/local/lib/libpcre.so.0 > #2 0x28f1d613 in msc_pregcomp_ex (pool=0xbfbfe398, pattern=0x2900a5b0 > "x_(?:key|file)\\b", options=36, _errptr=0xbfbfe418, > _erroffset=0xbfbfe414, match_limit=0, match_limit_recursion=0) at > msc_pcre.c:69 > #3 0x28f34974 in msre_op_rx_param_init (rule=0x2900a768, > error_msg=0xbfbfe478) at re_operators.c:87 > #4 0x28f3a948 in msre_rule_create (ruleset=0x285fb980, type=0, > fn=0x2859b030 > "/usr/local/apache2/conf/Includes/mod_security2/TEMP/modsecurity_crs_45_trojans.conf", > line=30, > targets=0x2900a598 "REQUEST_HEADERS_NAMES", args=0x2900a5b0 > "x_(?:key|file)\\b", > actions=0x2900a5c8 > "phase:2,rev:'2.0.5',t:none,t:lowercase,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Backdoor > access',id:'950110',tag:'MALICIOUS_SOFTWARE/TROJAN',tag:'WASCTC/WASC-01',tag:'OWASP_TOP_10/A7',tag:'PCI/5."..., > error_msg=0xbfbfe4d8) > at re.c:1535 > #5 0x28f3e697 in add_rule (cmd=0xbfbfe680, dcfg=0x28562ae0, type=0, > p1=0x2900a598 "REQUEST_HEADERS_NAMES", > p2=0x2900a5b0 "x_(?:key|file)\\b", > p3=0x2900a5c8 > "phase:2,rev:'2.0.5',t:none,t:lowercase,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Backdoor > access',id:'950110',tag:'MALICIOUS_SOFTWARE/TROJAN',tag:'WASCTC/WASC-01',tag:'OWASP_TOP_10/A7',tag:'PCI/5."...) > at apache2_config.c:608 > #6 0x0807e682 in invoke_cmd (cmd=0x28f50478, parms=0xbfbfe680, > mconfig=0x28562ae0, args=0x2859b27a "") at config.c:857 > #7 0x0807ec60 in ap_walk_config (current=0x2859b098, > parms=0xbfbfe680, section_vector=0x28555ca8) at config.c:1163 > #8 0x0807ed97 in ap_process_config_tree (s=0x2851a228, > conftree=0x2855d120, p=0x2850f018, ptemp=0x28553018) at config.c:1765 > #9 0x0806ab81 in main (argc=676384792, argv=0x2850f018) at main.c:644 |
From: Brian R. <bre...@gm...> - 2010-09-06 21:19:53
|
Still calling pcre_study(). Did you run a "make clean" after disabling study? Otherwise maybe that option is broken. Odd issue. Maybe you have hit some imposed resource limit via some other system setting? -B On Sep 6, 2010 1:26 PM, "Steffan Vigano" <sv...@bo...> wrote: On 9/6/2010 12:41 PM, Brian Rectanus wrote: > > > Looks like it is compiling a regex. Note the rege... It always seems to hangs there. As I shuffle some of the base rules in or out of the include directory, the lower portions of the back trace are different but the upper few sections are always the same. Playing with the configure option '--disable-pcre-study' (or --enable-pcre-study=no) unfortunately did not do anything. Even with it disabled, it still shows as frame #2. I uninstalled and reinstalled the latest PCRE but it didn't change. See below for a bt with that option off and it hanging while parsing a different rule. Thanks -S #0 0x28f67425 in find_minlength () from /usr/local/lib/libpcre.so.0 > #1 0x28f6790e in pcre_study () from /usr/local/lib/libpcre.so.0 > #2 0x28f1d613 in msc_pregcomp_ex (pool=0xbfbfe398, pattern=0x2900a5b0 > "x_(?:key|file)\\b", options=36, _errptr=0xbfbfe418, > > > > _erroffset=0xbfbfe414, match_limit=0, match_limit_recursion=0) at > msc_pcre.c:69 > #3 0x28f34974 in msre_op_rx_param_init (rule=0x2900a768, > error_msg=0xbfbfe478) at re_operators.c:87 > #4 0x28f3a948 in msre_rule_create (ruleset=0x285fb980, type=0, > fn=0x2859b030 > "/usr/local/apache2/conf/Includes/mod_security2/TEMP/modsecurity_crs_45_trojans.conf", > line=30, > targets=0x2900a598 "REQUEST_HEADERS_NAMES", args=0x2900a5b0 > "x_(?:key|file)\\b", > actions=0x2900a5c8 > "phase:2,rev:'2.0.5',t:none,t:lowercase,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Backdoor > access',id:'950110',tag:'MALICIOUS_SOFTWARE/TROJAN',tag:'WASCTC/WASC-01',tag:'OWASP_TOP_10/A7',tag:'PCI/5."..., > error_msg=0xbfbfe4d8) > at re.c:1535 > #5 0x28f3e697 in add_rule (cmd=0xbfbfe680, dcfg=0x28562ae0, type=0, > p1=0x2900a598 "REQUEST_HEADERS_NAMES", > p2=0x2900a5b0 "x_(?:key|file)\\b", > p3=0x2900a5c8 > "phase:2,rev:'2.0.5',t:none,t:lowercase,ctl:auditLogParts=+E,pass,nolog,auditlog,msg:'Backdoor > access',id:'950110',tag:'MALICIOUS_SOFTWARE/TROJAN',tag:'WASCTC/WASC-01',tag:'OWASP_TOP_10/A7',tag:'PCI/5."...) > at apache2_config.c:608 > #6 0x0807e682 in invoke_cmd (cmd=0x28f50478, parms=0xbfbfe680, > mconfig=0x28562ae0, args=0x2859b27a "") at config.c:857 > #7 0x0807ec60 in ap_walk_config (current=0x2859b098, parms=0xbfbfe680, > section_vector=0x28555ca8) at config.c:1163 > > > > #8 0x0807ed97 in ap_process_config_tree (s=0x2851a228, > conftree=0x2855d120, p=0x2850f018, ptemp=... > |
From: Steffan V. <sv...@bo...> - 2010-09-06 22:29:06
|
On 9/6/2010 2:19 PM, Brian Rectanus wrote: > > Still calling pcre_study(). Did you run a "make clean" after > disabling study? Otherwise maybe that option is broken. Odd issue. > Maybe you have hit some imposed resource limit via some other system > setting? > Yes... I ran make clean before recompiling. Seems that '--disable-pcre-study' clearly changes something in the build, as the the resulting mod_security2.so file size and cksum is different. But, as you noticed, the backtrace suggests that it is not in fact disabling pcre_study. I've also tried playing with different and sometimes ridiculous values for pcre-match-limit and pcre-match-limit-recursion. All to no avail. FreeBSD install is fairly vanilla. No kernel tweaks or the such. I can reproduce the problem on a different fresh install. Thanks again. -S |
From: Rainer J. <rai...@ki...> - 2010-09-07 08:22:43
|
On 07.09.2010 00:27, Steffan Vigano wrote: > > On 9/6/2010 2:19 PM, Brian Rectanus wrote: >> >> Still calling pcre_study(). Did you run a "make clean" after >> disabling study? Otherwise maybe that option is broken. Odd issue. >> Maybe you have hit some imposed resource limit via some other system >> setting? >> > > Yes... I ran make clean before recompiling. Seems that > '--disable-pcre-study' clearly changes something in the build, as the > the resulting mod_security2.so file size and cksum is different. But, > as you noticed, the backtrace suggests that it is not in fact disabling > pcre_study. I've also tried playing with different and sometimes > ridiculous values for pcre-match-limit and pcre-match-limit-recursion. > All to no avail. FreeBSD install is fairly vanilla. No kernel tweaks > or the such. I can reproduce the problem on a different fresh > install. Thanks again. > -S Could it be version confusion between /usr/local/lib/libpcre.so.0, the pcre used by PHP (which you also load; possibly pcre is compiled in) and the one that comes bundled with Apache? See whether your "httpd" binary and "/usr/local/apache2/modules/libphp5.so" are dynamically linked against any pcre library, and also whether they contain any pcre symbols themselves, e.g. via nm /usr/local/apache2/modules/libphp5.so | grep pcre_ (some of the hits might be php functions). Regards, Rainer |
From: Steffan V. <sv...@bo...> - 2010-09-07 23:40:55
|
On 9/7/2010 1:22 AM, Rainer Jung wrote: > Could it be version confusion between /usr/local/lib/libpcre.so.0, the > pcre used by PHP (which you also load; possibly pcre is compiled in) and > the one that comes bundled with Apache? See whether your "httpd" binary > and "/usr/local/apache2/modules/libphp5.so" are dynamically linked > against any pcre library, and also whether they contain any pcre symbols > themselves, e.g. via > > nm /usr/local/apache2/modules/libphp5.so | grep pcre_ > > (some of the hits might be php functions). Most of the hits are php related. It seems you're on to something, because if I start with a fresh BSD install, mimic my existing setup with the exception of installing PHP, then all of the base_rules load up fine (but only if I pass the --disable-pcre-study during configuration of mod_sec) . Below is the output of that command you suggested. Not sure what it means. Thanks again for all the help. nsvillage [/usr/local/src/php-5.2.14]# nm /usr/local/apache2/modules/libphp5.so | grep pcre_ 0013cab0 T _pcre_find_bracket 001534e0 t pcre_clean_cache 00638fa0 D pcre_functions 00154420 T pcre_get_compiled_regex 00153e70 T pcre_get_compiled_regex_cache 001543a0 T pcre_get_compiled_regex_ex 0065e200 B pcre_globals 00153490 t pcre_handle_exec_error 00639060 D pcre_module_entry 00444460 R php__pcre_OP_lengths 00434120 R php__pcre_default_tables 00151f50 T php__pcre_is_newline 001521f0 T php__pcre_ord2utf8 00152f00 T php__pcre_try_flipped 00434560 R php__pcre_ucd_records 004355a0 R php__pcre_ucd_stage1 004377a0 R php__pcre_ucd_stage2 00444560 R php__pcre_ucp_gentype 004444d4 R php__pcre_utf8_table1 004444ec R php__pcre_utf8_table1_size 004444f0 R php__pcre_utf8_table2 00444508 R php__pcre_utf8_table3 00444520 R php__pcre_utf8_table4 00444980 R php__pcre_utt 004445e0 R php__pcre_utt_names 00444c94 R php__pcre_utt_size 001530b0 T php__pcre_valid_utf8 00152060 T php__pcre_was_newline 00153220 T php__pcre_xclass 00157270 t php_do_pcre_match 00153610 t php_free_pcre_cache 0065bd00 B php_pcre_callout 001440f0 T php_pcre_compile 00143760 T php_pcre_compile2 00144130 T php_pcre_config 00151a30 T php_pcre_copy_named_substring 001515e0 T php_pcre_copy_substring 001502f0 T php_pcre_exec 00638f94 D php_pcre_free 00151490 T php_pcre_free_substring 00151480 T php_pcre_free_substring_list 001512b0 T php_pcre_fullinfo 001519d0 T php_pcre_get_named_substring 00151800 T php_pcre_get_stringnumber 00151640 T php_pcre_get_stringtable_entries 001514a0 T php_pcre_get_substring 00151520 T php_pcre_get_substring_list 00155280 T php_pcre_grep_impl 00151aa0 T php_pcre_info 00151b30 T php_pcre_maketables 00638f90 D php_pcre_malloc 001567b0 T php_pcre_match_impl 00152270 T php_pcre_refcount 001551f0 T php_pcre_replace 00154490 T php_pcre_replace_impl 00156140 T php_pcre_split_impl 00638f9c D php_pcre_stack_free 00638f98 D php_pcre_stack_malloc 00152c80 T php_pcre_study 00153210 T php_pcre_version village [/usr/local/src/]# village [/usr/local/src/]# nm /usr/local/apache2/bin/httpd | grep pcre 080fe8f0 B pcre_callout 080d7a40 T pcre_compile 080d1cd0 T pcre_config 080f96e0 d pcre_default_tables 080d4d70 T pcre_exec 080f96c4 D pcre_free 080d1b80 T pcre_fullinfo 080d1ae0 T pcre_info 080f96c0 D pcre_malloc 080f96cc D pcre_stack_free 080f96c8 D pcre_stack_malloc 080d1930 T pcre_version village [/usr/local/src/]# |
From: Steffan V. <sv...@bo...> - 2010-09-21 22:52:38
|
I've been contacted directly by several folks with the same issue looking to see if I solved it, so here's a quick update for this thread for others that are seeing similar issues. Still no luck on this. But.... If I build everything using the FreeBSD ports system, then everything works fine. Guess I'll stick with that for now. Thanks for all the help and suggestions. -S |