Bug 533124 - Moved and missing configuration files completely break mod_security and prevent httpd from starting
Summary: Moved and missing configuration files completely break mod_security and preve...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mod_security
Version: 11
Hardware: All
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Michael Fleming
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-05 08:07 UTC by Daniel McNamara
Modified: 2009-12-07 07:28 UTC (History)
7 users (show)

Fixed In Version: 2.5.10-2.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-10 17:42:58 UTC


Attachments (Terms of Use)

Description Daniel McNamara 2009-11-05 08:07:35 UTC
Description of problem:

mod_security-2.5.10-1 has moved and removed some rulesets but the /etc/http/conf.d/mod_security.conf file was not updated to reflect these changes resulting in http failing to start the next time it is restarted.

The moving and removal of the rulesets seems to be completely arbitrary and this package has clearly had no testing done.


Version-Release number of selected component (if applicable):

mod_security-2.5.10-1


How reproducible:

Everytime. Tested it on a brand new sandbox vm to ensure my production webhosting setup was not at fault.

Steps to Reproduce:

1.

Install mod_security-2.5.10-1 or yum update to it and restart httpd

2.

HTTP will fail to restart with error such as:

Stopping httpd:                                            [  OK  ]
Starting httpd: httpd: Syntax error on line 207 of /etc/httpd/conf/httpd.conf: Syntax error on line 14 of /etc/httpd/conf.d/mod_security.conf: Could not open configuration file /etc/httpd/modsecurity.d/modsecurity_crs_20_protocol_violations.conf: No such file or directory
                                                           [FAILED]

3.

Going checking for files and find some of them have been moved and some have plain gone.
  
Actual results:

http refuses to start

Expected results:

Config file pointing to correct files allow httpd to start in the default configuration

Additional info:


I did additional checks between mod_security-2.5.9-1 and mod_security-2.5.10-1

The mod_security.conf file does not diff between the two and has remained untouched. The rulesets however have been drastically changed:

[root@firefly conf.d]# rpm -q mod_security
mod_security-2.5.9-1.fc11.x86_64
root@firefly conf.d]# rpm -ql mod_security
/etc/httpd/conf.d/mod_security.conf
/etc/httpd/modsecurity.d
/etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
/etc/httpd/modsecurity.d/modsecurity_crs_20_protocol_violations.conf
/etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf
/etc/httpd/modsecurity.d/modsecurity_crs_23_request_limits.conf
/etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf
/etc/httpd/modsecurity.d/modsecurity_crs_35_bad_robots.conf
/etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf
/etc/httpd/modsecurity.d/modsecurity_crs_45_trojans.conf
/etc/httpd/modsecurity.d/modsecurity_crs_50_outbound.conf
/etc/httpd/modsecurity.d/modsecurity_localrules.conf
/etc/httpd/modsecurity.d/optional_rules
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_20_protocol_violations.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_21_protocol_anomalies.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_40_generic_attacks.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_comment_spam.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_tight_security.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_55_marketing.conf

[root@firefly conf.d]# rpm -q mod_security
mod_security-2.5.10-1.fc11.x86_64
/etc/httpd/conf.d/mod_security.conf
/etc/httpd/modsecurity.d
/etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf
/etc/httpd/modsecurity.d/modsecurity_crs_10_global_config.conf
/etc/httpd/modsecurity.d/modsecurity_localrules.conf
/etc/httpd/modsecurity.d/optional_rules
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_20_protocol_violations.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_21_protocol_anomalies.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_40_generic_attacks.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_comment_spam.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_tight_security.conf
/etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_55_marketing.conf

Note that most of the rulesets in mod_security-2.5.10-1 have been moved a further subdirectory down into optional_rules - not also that several of the rulesets have been removed completly meaning that even when you fix the config to point to the updated paths the webserver is now unprotected against several forms of attack,

The proven lack of testing of the package update is deeply disappointing.

Comment 1 Daniel McNamara 2009-11-05 08:31:23 UTC
Looking at this again it appears most of the removed ruleset files are duplications - which is understandable. The main config being updated however is not.

Comment 2 bugzilla.redhat.com 2009-11-06 00:47:06 UTC
It also appears as if an entire subdirectory of rules (base_rules) is missing when compared to the official core ruleset v2.0.2.

Comment 3 P H 2009-11-06 03:02:37 UTC
There is the same problem in Fedora 10.

Web server down due to this.

Comment 4 Michael Fleming 2009-11-06 09:26:28 UTC
I'm looking into this further and will push a new stable build once it's found to be OK.

I've noticed that no one had commented on the package while in updates-testing - I would encourage users to do so in future (for all packages you'd consider important).

Comment 5 Eli Wapniarski 2009-11-06 17:21:44 UTC
With all due respect. Your making the assumption that a regular user actually knows that they need to test mod_security from updates_testing. Also, that they have resources to test it.

In my case, I only have my production environment to work with so I am updating my packages directly from updates.

I realize that resources are limited for many. However, not doing the basic qa to make sure that the Web Server comes up...


Its one of those things that make you go hmmm. :)

Comment 6 Michael Fleming 2009-11-07 01:31:56 UTC
Updated builds are currently running through koji after a successful scratch build and install (EL-5). Will push out the new builds to stable when completed.

Comment 7 Fedora Update System 2009-11-07 01:34:59 UTC
mod_security-2.5.10-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/mod_security-2.5.10-2.fc10

Comment 8 Fedora Update System 2009-11-07 01:35:05 UTC
mod_security-2.5.10-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mod_security-2.5.10-2.fc12

Comment 9 Fedora Update System 2009-11-07 01:35:10 UTC
mod_security-2.5.10-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mod_security-2.5.10-2.fc11

Comment 10 antony osullivan 2009-11-07 01:46:56 UTC
I was writing to say I had the same thing for FC11... but I got a "Mid-air collision detected!" as I went to submit!

I am very pleased and thankful that this has been fixed quickly.

Thank you!

Comment 11 Fedora Update System 2009-11-10 17:42:52 UTC
mod_security-2.5.10-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2009-11-10 17:53:23 UTC
mod_security-2.5.10-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 John Griffiths 2009-11-16 19:21:35 UTC
The new mod_security-2.5.10-2.fc10.i386 breaks bugzilla-3.2.5-1.fc10.noarch. I'm working on localrules to allow cgi in bugzilla to work, but wow, why should I?

Comment 14 antony osullivan 2009-11-16 20:53:45 UTC
Mr JG I do not understand what you are trying to say...

Comment 15 Ray Todd Stevens 2009-11-16 21:23:04 UTC
OK this seems to be fixed and httpd loads.    BUT now it breaks nagios.  :-(

[msg "Transactional Anomaly Score (score 50): Detects JavaScript location/document property access and window access obfuscation"] [hostname "sysdoc.safespeak.com"] [uri "/nagios/cgi-bin//statusmap.cgi"] 

Do we need a new bug report on that???

Comment 16 John Griffiths 2009-11-16 21:36:48 UTC
Sorry. I was not clear.

I was saying that the new mod_security breaks bugzilla, and that I was working on local rules to allow bugzilla to be able to search again, but it is my opinion that rules for things like bugzilla should be part of a package, either mod_security or Bugzilla. I know that is asking a lot, but to have a working production system and do an update and have services that were working no longer work is disconcerting and irritates the user base.

Here are the local rules for allowing bugzilla to run.

<Location /bugzilla/buglist.cgi>
SecRuleRemoveById 959913
SecRuleRemoveById 959914
SecRuleRemoveById 960904
SecRuleRemoveById phpids-19
</Location>

Comment 17 John Griffiths 2009-11-16 22:18:25 UTC
Found more problems areas with cgi scripts from Bugzilla so the new local rules are:

<Location /bugzilla>
SecRuleRemoveById 950108
SecRuleRemoveById 959913
SecRuleRemoveById 959914
SecRuleRemoveById 960010
SecRuleRemoveById 960012
SecRuleRemoveById 960904
SecRuleRemoveById phpids-19
SecRuleRemoveById phpids-21
SecRuleRemoveById phpids-23
</Location>

There may be more to come, but so far so good.

Comment 18 Michael Fleming 2009-11-16 22:26:18 UTC
Good morning, this is your package maintainer speaking,

This is a closed bug. Unless there's an issue directly related to the original report, it'll stay that way.

If there is a separate package-related issue needing attention, please open a new bug with the appropriate info. 

Also bear in mind that I'm responsible for the packaging of the application, not the rulesets. I would encourage users - especially those running it in production - to join the mailing lists:

https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set (for the Core Rules Set)

https://lists.sourceforge.net/lists/listinfo/mod-security-users

Comment 19 Fedora Update System 2009-12-07 07:28:28 UTC
mod_security-2.5.10-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.