Comodo security update breaks apache
It seems like Comodo updated the following file which prevents apache from being able to restart:
/etc/apache2/conf.d/modsec_vendor_configs/comodo_apache/30_Apps_OtherApps.conf
When trying to get apache to restart you'll likely see this:
Startup Log
Jun 05 01:53:00 myserver.com systemd[1]: Starting Apache web server managed by cPanel EasyApache...
Jun 05 01:53:01 myserver.com restartsrv_httpd[2481670]: AH00526: Syntax error on line 6035 of /etc/apache2/conf.d/modsec_vendor_configs/comodo_apache/30_Apps_OtherApps.conf:
Jun 05 01:53:01 myserver.com restartsrv_httpd[2481670]: Error creating rule: Error compiling pattern (offset 4): invalid range in character class
Jun 05 01:53:01 myserver.com systemd[1]: httpd.service: Control process exited, code=exited, status=1/FAILURE
Jun 05 01:53:01 myserver.com systemd[1]: httpd.service: Failed with result 'exit-code'.
Jun 05 01:53:01 myserver.com systemd[1]: Failed to start Apache web server managed by cPanel EasyApache.
Log Messages
Jun 5 01:53:01 web02 systemd[1]: Failed to start Apache web server managed by cPanel EasyApache.
Jun 5 01:53:01 web02 restartsrv_httpd[2481670]: AH00526: Syntax error on line 6035 of /etc/apache2/conf.d/modsec_vendor_configs/comodo_apache/30_Apps_OtherApps.conf:
I changed line 6035 to this and I was able to restart:
SecRule ARGS_POST:closedate "!@rx ^[\d:-]+$" \
"t:none,t:removeWhitespace"
Seems like the - was out of place. Hopefully this can help someone else.
-
Hey there! This is a known issue with the recent update and we're tracking this through case CPANEL-47639. I've added your comments to that case as well, and I if hear anything an my end I'll be sure to post an update!
0 -
Hello Nick Vee
Thank you, that rule has actually been in place for a while now. It is just that since it contained a syntactically invalid regexp, it was simply ignored in the past. So it wouldn't have worked anyway.
With the new ea-modsec29 RPM we released yesterday to address two security CVE's, a PCRE2 section was added as well. PCRE2 is used to validate regexp's properly. Once it detected that invalid regexp in Comodo's ruleset, it barfed and couldn't recover.
We have attempted to contact Comodo to make them aware of the issue. I'm not optimistic that anything will happen, as I am not sure that this product (Comodo WAF) is still being maintained.
0 -
I can not locate the CPANEL-47639 case and I am still not sure how to get Apache running again. Please advise.
0 -
We have an article here that may help.
0 -
Thanks Peter, but is there not a way to reinstall the previous version until Comodo gets it fixed. I do not know how to fix the syntax error and when I disable a rule Apache will still not start. There appears to be more than one rule effected.
0 -
Hello,
Downgrading to the previous Mod Security package is not advised as that would open your server up to the 2 security vulnerabilities that were patched in the new version. The problem isn't the new Mod Security package, it's in the rules themselves. That rule has been in there for several years but hasn't been working since it was invalid.From what I can tell, the Comodo WAF ruleset is no longer being maintained. Unless I hear from them, I strongly recommend removing the ruleset since it is likely outdated anyway.
For now though, commenting out that rule should do the trick. All the other rules should still work, just that one won't (but it didn't anyway), so not really a loss.0 -
I'd like to comment by saying that the regex below is not correct:
SecRule ARGS_POST:closedate "!@rx ^[\d:-]+$" \
"t:none,t:removeWhitespace"The COMODO WAF rule with ID 240590 targets a potential SQL injection vulnerability in LimeSurvey (CVE-2015-5078). It triggers when all these conditions are met:
1. The requested URL ends with:
index.php/admin/dataentry/sa/insert2. The POST parameter `subaction` exactly equals `insert`
3. The POST parameter `closedate` contains any characters other than digits (0-9), colon (:), or dash (-)
The relevant part causing the Apache startup error was the regex in condition #3:
SecRule ARGS_POST:closedate "!@rx ^[\d:-]+$"
This syntax is invalid because this rule uses the character class
[\d-:]
, which is invalid in PCRE because\d
inside[]
is not reliably interpreted as[0-9]
and results in an invalid range when combined with-:
The correct, safe regex is:
SecRule ARGS_POST:closedate "!@rx ^[0-9:-]+$"
This explicitly lists allowed characters and avoids the invalid range error.
With this fix, Apache starts normally, and the rule continues to function as intended, detecting suspicious `closedate` input on the specified LimeSurvey admin endpoint.
Hopefully this helps.
0 -
I got served this broken update last night, luckily others already experienced it and with a quick search on internet issue was fixed locally. Hopefully next update doesn't break it again!
0
Please sign in to leave a comment.
Comments
8 comments