OLS 1.8.2 upgrade std::length_error + breaks mod_security

#1
Opgraded to OLS v1.8.2 (from v1.7.9), Webadmin works however all my sites get blocked and I encounter 2 (new) issues:

1. the stderr.log gives the following error (same one), every 5 minutes:
2024-09-15 09:31:23.840 [STDERR] terminate called after throwing an instance of 'std::length_error'
what(): basic_string::resize
2. mod_security now blocks EVERYTHING (browser returns code 301 - moved permanently).
When I disable mod_security as a module, my websites run again perfectly.
modsec_debug.log has only lvl 4 & lvl 9 entries, so no errors recorded.
No settings have been changed from v1.7.9, which ran perfectly with the current (same) mod_security module enabled, same filter file.

From the debug log all actions seem to show a pass:
[/] [4] Running (disruptive) action: pass.
Please help, any suggestions? (modsec_debug.log attached)

---------------------------------
OS: AlmaLinux v9.4 x64
PLATFORM_ID="platform:el9"
 

Attachments

#8
Any updates on this issue, please?
We have been running the v1.8.2 OLS webserver without ModSecurity, just so it actually displays pages.
This is how any and all our web pages are returned (index.html) in Firefox 115.14.0esr (64-bit) when trying to access them (with ModSecurity module enabled):
Just to say that I've downgraded to OpenLiteSpeed version 1.7.19, and ModSecurity worked fine with the OWASP or COMODO rules. Then I upgraded to 1.8.1, and I see that it is working fine again. However, if I go to 1.8.2, it is bugged. :)

I'm on Ubuntu 22.04 with OWASP. I recommend backing up and trying to downgrade.

I've used this command: /usr/local/lsws/admin/misc/lsup.sh -v 1.8.1 or 1.7.19 as you see it fit, then restarted OLS. Just an idea—maybe this will help until the OLS development team resolves the issue. Peace! :)
 
Last edited:
#10
Well if you already installed/upgraded to v1.8.2 and you have to ask... you probably don't have it. This would be surprising, if not everybody is affected, meaning probably the issue could be int the rule list? Or perhaps you don't have mod_security plugin activated in the OLS webserver?
 

Cold-Egg

Administrator
#11
Based on the OLS developers' review, it appears that the issue is related to the new ModSecurity library. As a result, we will be releasing a new v1.8.2 OLS package that includes the previous ModSecurity library.
 
#12
Hi all,

I'm one of the ModSecurity developers and try to solve this problem.

There is an open issue on ModSecurity's GH page, but unfortunately I was not able to reproduce this error neither with Nginx nor the library's own regression test.

Could you send us a core dump in e-mail to modsecurity at owasp dot org address?
 
#15
wanted to ask the same thing :) we've been running OLS without mod_security for almost a month now. Should we downgrade or still hold out for a soon to be released update, patch maybe?
 
#16
We can't fix the issue because we can't reproduce that (neither with Nginx nor library's own regression test framework). This is why I asked a core dump or something help...
 
#19
For the moment I downgraded the ModSecurity module to v3.0.12 found in the previous OLS release. So OLS 1.8.2 + mod_security v3.0.12 still works, for anyone encountering this same issue.
Take your time devs, but please fix its implementation, going forward. Thank you.
 
Top