owasp-modsecurity / ModSecurity

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
https://www.modsecurity.org
Apache License 2.0
8.23k stars 1.61k forks source link

ModSecurity 3.0.13 error std::length_error + blocking ALL site requests #3259

Closed stevenkain closed 3 weeks ago

stevenkain commented 1 month ago

After upgrading to latest version of ModSecurity v3.0.13 there is a new error written to the stderr.log every 5 minutes:

2024-09-15 10:08:22.915 [STDERR] terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::resize

At the same time, ModSecurity now blocks every single page request for my site (browser returns code 301 - moved permanently). When I turn off the ModSec module within the WebServer, everything starts running fine once again.

There seem to be no other errors and the only entries in the debug.log are lvl 4 and lvl 9, all of them seem to pass:

[/] [4] Running (disruptive) action: pass.

Attached: stderr.log modsec_debug.log (modsec_audit.log is always empty, no point of attaching it)


OS: AlmaLinux v9.4 x64 PLATFORM_ID="platform:el9" WebServer: OpenLiteSpeed v1.8.2 ModSec v3.0.13 implemented as a module with OpenLiteSpeed v1.8.2 Comodo rules set (free version) for Litespeed v1.241 "_cwaf_rulesls-1.24"

modsec_debug.log stderr.log

airween commented 1 month ago

Hi @stevenkain,

do you have audit.log? If yes, could you share that with us, but please not here but in email: modsecurity@owasp.org.

stevenkain commented 1 month ago

as I mentioned in my initial post, the audit.log is always empty. 0 bytes

The Module Parameters in my OpenLiteSpeed WebServer are:

modsecurity  on
modsecurity_rules `
SecRuleEngine on
SecDebugLogLevel 9
SecDebugLog /var/log/ls_ws/modsec_debug.log
SecAuditEngine on
SecAuditLog /var/log/ls_ws/modsec_audit.log
SecAuditLogType Serial
SecAuditLogStorageDir /var/log/ls_ws/
`
modsecurity_rules_file          /usr/local/lsws/conf/comodo/rules.conf
airween commented 1 month ago

as I mentioned in my initial post, the audit.log is always empty. 0 bytes

sorry, I didn't notice that line.

The Module Parameters in my OpenLiteSpeed WebServer are:

modsecurity  on
modsecurity_rules `
SecRuleEngine on
SecDebugLogLevel 9
SecDebugLog /var/log/ls_ws/modsec_debug.log
SecAuditEngine on
SecAuditLog /var/log/ls_ws/modsec_audit.log
SecAuditLogType Serial
SecAuditLogStorageDir /var/log/ls_ws/
`
modsecurity_rules_file          /usr/local/lsws/conf/comodo/rules.conf

Thanks, I try to investigate the cause based on the available information.

airween commented 1 month ago

Do you have any special build environment/setting/...? How did you build the library? I mean could you show your config.log's 7th line? It seems something like

  $ ./configure --prefix=/usr ...

or very similar. The point is that your used options (+ other exported variables, eg. if you have any CFLAGS/CXXFLAGS).

stevenkain commented 1 month ago

Nothing special, ModSecurity v3.0.13 comes packaged with the newest OpenLiteSpeed v1.8.2. I simply upgraded trough Method 2 described on the ols.org website

Basically: wget https://raw.githubusercontent.com/litespeedtech/openlitespeed/master/dist/admin/misc/lsup.sh

then run: ./lsup.sh No other flags or options used, nothing changed in the config from upgrading OLS v1.7.19 (packaged with libmodsecurity v3.0.11). Displayed installation successful, no error during upgrade.

P.S: maybe this could help: is how any and all my web pages are returned (index.html) in Firefox 115.14.0esr (64-bit) when I try to access them with ModSecurity module enabled in the OLS webserver:

Screenshot from 2024-09-16 13-52-53

airween commented 1 month ago

Thanks, this is an important information. Seems like LiteSpeed delivers the solution in binary format - and therefore I don't know what modifications they have been made.

On the weekend I tried to reconstruct the issue with "vanilla" libmodsecurity3 and an Nginx (based on your logs - I assumed that the URI is just the /), but I was not able.

May be you should ask LiteSpeed to investigate this issue.

stevenkain commented 1 month ago

May be you should ask LiteSpeed to investigate this issue.

I did, even before coming here: https://forum.openlitespeed.org/threads/ols-1-8-2-upgrade-std-length_error-breaks-mod_security.6194/

No feedback yet.

stevenkain commented 1 month ago

"_Based on the OLS developers' review, it appears that the issue is related to the new ModSecurity library_"

Please fix the current version of the ModSecurity Library, which seems to be broken for many (most?) of us.

airween commented 1 month ago

"_Based on the OLS developers' review, it appears that the issue is related to the new ModSecurity library_"

Please fix the current version of the ModSecurity Library, which seems to be broken for many (most?) of us.

Indeed, it must be fixed - but unfortunately until we can't reproduce the issue, we can't handle the problem.

Could you produce a core dump?

airween commented 1 month ago

I asked the core dump on OLS's forum.

airween commented 3 weeks ago

Issue was solved on OLS's site: https://forum.openlitespeed.org/threads/ols-1-8-2-upgrade-std-length_error-breaks-mod_security.6194/

Conclusion: older versions of GCC (<= 7) probably compiles incorrect binary.

I'm closing this one.