Skip to main content

Comodo security update breaks apache

Comments

8 comments

  • cPRex Jurassic Moderator

    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
  • cPanelPeter cPanel Staff

    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
  • J-Mac

    I can not locate the CPANEL-47639 case and I am still not sure how to get Apache running again. Please advise.

    0
  • J-Mac

    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
  • cPanelPeter cPanel Staff

    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
  • Levaro Sintex

    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/insert

    2. 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
  • Girts Legzdins

    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.