http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1359 "Interpretation conflict in ModSecurity (mod_security) 2.1.0 and earlier allows remote attackers to bypass request rules via application/x-www-form-urlencoded POST data that contains an ASCIIZ (0x00) byte, which mod_security treats as a terminator even though it is still processed as normal data by some HTTP parsers including PHP 5.2.0, and possibly parsers in Perl, and Python." Based on version numbers, all FE releases are affected.
Thanks for the reminder Ville. Ivan (Ristic, ModSecurity author) hasn't released an update for the 1.9.x branch as yet to fix this, but does have a rule for 2.x and up that mitigates the issue pending a full release of 2.1.1 (and I would assume a 1.9.5 version) From http://www.modsecurity.org/blog/archives/2007/03/modsecurity_asc.html: SecRule REQUEST_BODY "@validateByteRange 1-255" \ "log,deny,phase:2,t:none,msg:'ModSecurity ASCIIZ Evasion Attempt' I'm going to run up a local package of ModSecurity 2.1.0 (+Core Rules and the above as a "local" rule) this morning and try this on my own site (www.enlartenment.com) prior to adding it to Extras (should it work out OK). I've been meaning to update the version for a while but time constraints got the better of me. Be warned however that the configuration and rule syntax has changed since 1.9.x (admins are going to have to make some manual changes if they've got local additions) but on the upside it's 200% faster and the rule syntax allows for more flexibility. If there's any objections by all means let me know and I'll hold off until a proper 1.9.x fix is available.
Folks, I've run up some preliminary 2.1.0 RPMs for Core 5 and 6 (i386 and x86_64, no ppc or Rawhide here sorry) at http://www.enlartenment.com/modsecurity/ for those interested in giving them a test prior to me importing them into CVS. It's a fairly serious upgrade and I want to spring as few surprises on users as I can - however if you've not tinkered too much with 1.9's config as I've shipped it you should see no problems. I've turned on the Core Rules set (minus 2 dodgy sets Ivan is aware of) and added the above rule to a local set to ideally fix the reported vulnerability. The server they're hosted on is also running this version and ruleset as a proof-of-concept / eat-my-own-dogfood demonstration. Any feedback appreciated.
If the rules from 1.9.x are not usable with 2.1.0 as is, they should be marked as %config, not %config(noreplace). And reverted back to %config(noreplace) later in the future where it is no longer expected that people will not be upgrading from 1.9.x to the current version at that time, but rather from a version whose config syntax is compatible.
Packages with the aforementioned suggestion (%config not %config(noreplace)) have been uploaded (same location as the previous set, release is 2.1.0-0.4 this time around). If there's no niggles or issues I'll fold this into CVS devel so the bleeding-edge users can give it a whirl, before unleashing it on the general public.
No problems or complaints in -devel, been running fine on my FC6 box. Ergo 2.1.0-3 has been rolled out to FC5 and FC6. Interestingly, Ivan did put out a patch for 1.9.4 - but only for the Apache 1.3.x DSO :-(