Re: [mod-security-users] Nulls in post cause false negative (Bug?)

[<sre...@g8...>]

>    No, it is definitely a bug - I'll upload a fix to the CVS
>    tonight.

Wow, that's quick :)

>    The bug was that there was no range checking for POST
>    payloads (range 0-255 was hardcoded). Normally something like
>    this would have been caught by the SecFilterForceByteRange
>    check.
>
>    I am not really sure whether to implement an additional
>    check for the null byte. It is aleady being done for
>    all content types other than "application/x-www-form-urlencoded"
>    (to allow for scanning of uploaded files, even if they are in
>    a binary format).
>
>    I feel that it would be better to let SecFilterForceByteRange
>    catch the null byte attack. What do you think?

I spent a little bit of time looking through mod_security.c.  It seems
as if you'd still want this case to be caught when
"SecFilterForceByteRange 0 255" was given as a setting.  The program
on the receiving end (a cgi in this case) still sees 0x0 coming
though, and everything afterwards.  In some languages, ^@ is a
perfectly valid character.

This is a tricky one, since regexec() is expecting a null terminated
string.  Perhaps remove_binary_content() after normalise_uri() would
be the ticket.

This is more of an RFE, but it would also be nice to allow arbitrary
binary data in keyword patterns.  (Like "\177ELF" :).

Thanks for the quick response.

-- 
Steve