It has been brought to our attention that a fault in the ModSecurity parsing code has been discovered and published. (No, we have not been contacted by the author, either before or after the publication. We learned about the problem from a third party.) The fault makes it possible to sneak an attack payload past a class (not all, as you will see below) of ModSecurity rules.
The rules that use variables that refer to request parameters (e.g. ARGS) can be evaded in certain circumstances, as follows: 1) parameters must be transported in an application/x-www-form-urlencoded request body, 2) an un-encoded NULL byte (ASCIIZ) must be embedded in the payload and 3) the parser used by the web application must do things differently. (Apparently, PHP < 5.2.0 cannot be attacked in this way but >= 5.2.0 can. Of course, the problem is not specific to PHP, but at this point we don't know exactly how other environments are impacted. Unless you know differently you should treat the situation as if the evasion is possible.) The ASCIIZ byte will cause the parser to terminate prematurely, missing some data.
The logging features are not affected.
A ModSecurity update will be released to deal with this issue. However, an update is not the only way to deal with the problem. it is possible to use ModSecurity itself to detect and prevent evasion. Simply add the following rule to your rule set:
SecRule REQUEST_BODY "@validateByteRange 1-255" \ "log,deny,phase:2,t:none,msg:'ModSecurity ASCIIZ Evasion Attempt'"
All your other rules can remain intact. The above rule should not result in false positives under normal circumstances.
Please note that, not having been notified in advance, there was not enough time to research all aspects of this evasion technique as thoroughly as we would like. We are sending this email to notify our users and help them mitigate the problem quickly. The information presented here may end up being a work in progress, in which case we will follow up as soon as we learn more.
And, for the record, I am not at all happy with the fact the issue was not disclosed to us in advance. We take security very seriously; a responsible disclosure would have allowed us to have an updated version of ModSecurity available for download at the same time as the disclosure.
Update: This was fixed a while ago, with the release of ModSecurity v2.1.1.
