Red Hat Bugzilla – Bug 231728
CVE-2007-1359: mod_security <= 2.1.0 request rule bypass
Last modified: 2007-11-30 17:11:58 EST
"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)
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.
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
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 :-(