Ryan Barnett rcbarnett at gmail.com
Tue Feb 15 09:26:50 EST 2011

As promised, here is an updated ModSecurity ruleset.  with the use of the
ModSecurity Lua API, we (myself and Josh Zatlin of PureHacking) came up
with a new Generation 2 detection mechanism similar to what Brian Sullivan
(Adobe) presented below.

First step is to inspect the ARGS and REQUEST_HEADERS data using a regex
to match on potential floating point payloads -

SecRule ARGS|REQUEST_HEADERS "[0-9\.]{12,}e-[0-9]{3,}"

If a payload is found that matches the regex check, ModSecurity will
execute an external Lua script.  The lua script then extracts out
payloads, strips out the "." and then searches for the MagicDoSNumber.  If
this is found, then a TX variable is exported -


function main()

  local Pattern = 2225073858507201;

  -- Get the ModSec collections
  local Headers = m.getvars("REQUEST_HEADERS");
  local Args = m.getvars("ARGS");

  for i = 1, #Headers do
    FilteredPattern,NumChanges=string.gsub(Headers[i].value, "[.]", "")
    if string.gmatch(FilteredPattern, Pattern) then
      m.setvar("tx.floatingpointdos", Headers[i].name)
      return ("Potential Floating Point DoS Attack via variable: "
..Headers[i].name ..  ".");
  for i = 1, #Args do
    FilteredPattern,NumChanges=string.gsub(Args[i].value, "[.]", "")
    if string.gmatch(FilteredPattern, Pattern) then
      m.setvar("tx.floatingpointdos", Args[i].name)
      return ("Potential Floating Point DoS Attack via variable: "
..Args[i].name ..  ".");
  return nil;


Then we have one follow-up rule that checks if the TX:FLOATINGPOINTDOS
variable is set -

SecRule TX:FLOATINGPOINTDOS ".*" "phase:2,t:none,log,block,msg:'Floating
Point DoS Payload Found.',logdata:'Location:

We have conducted some tests with different payloads and this appears to
work pretty well.  If you find any issues please let me know.


On 2/13/11 2:33 PM, "Jim Manico" <jim at manico.net> wrote:

>It's not that tough to blacklist this vuln while you are waiting for your
>team to patch your JVM (IBM and other JVM's have not even patched yet).
>I've seen three generations of this filter already. Walk with me, Rafal
>and I'll show you. :)
>1) Generation 1 WAF rule (reject one number only)
>This mod security rule only blocks a small portion of the DOSable range.
>The mod security team is working to improve this now (no disrespect meant
>at all!)
>SecRule ARGS|REQUEST_HEADERS "@contains 2.2250738585072012e-308"
>"phase:2,block,msg:'Java Floating Point DoS Attack',tag:'CVE-2010-4476'"
>Reference: http://mobile.twitter.com/modsecurity/status/35734652652093441
>2) Generation 2 blacklist rejection J2EE filter (reject entire vulnerable
>Team Adobe came up with this. It's actually quite accurate in *rejecting
>input* in the DOSable JVM numeric range:
>public static boolean containsMagicDoSNumber(String s) {
>   return s.replace(".", "").contains("2225073858507201");
>Reference: http://blogs.adobe.com/asset/2011/02/year-of-the-snail.html
>3) Generation 3 IEEE data rounding J2EE validation POC (FTW from Brian
>This is code from Brian Chess at HP/Fortify.  This a fairly impressive
>approach to this problem. I'm in the process of integrating this fix into
>ESAPI. This approach detects the evil range before trying to call
>parseDouble and returns the IEEE official value for any double in this
>range ( 2.2250738585072014E-308 ).
>private static BigDecimal bigBad;
>private static BigDecimal smallBad;
>static {
>    BigDecimal one = new BigDecimal(1);
>    BigDecimal two = new BigDecimal(2);
>    BigDecimal tiny = one.divide(two.pow(1022));
>    // 2^(-1022) ­ 2^(-1076)
>    bigBad = tiny.subtract(one.divide(two.pow(1076)));
>    //2^(-1022) ­ 2^(-1075)
>     smallBad = tiny.subtract(one.divide(two.pow(1075)));
>if (arg == null) return false;  // arg is null?  return.
>String noDot = arg.replace(".", "");
>if (!noDot.contains("2225073858507201")) return false;
>// magic value not present?  return.
>BigDecimal bd;
>try {
>        bd = new BigDecimal(arg);
>} catch (NumberFormatException e) {
>        return false;  // can't parse?  return.
>if (bd.compareTo(smallBad) < 0 || bd.compareTo(bigBad) >
>0) return false;  // smaller than the smallest bad value or larger than
>the largest bad value?  Return
> // if you get here you know you're looking at a bad value.  The final
>value for any double in this range is supposed to be
>Reference: via email direct from Brian Chess
>_*Dr.*_ Chess, I'm very impressed.
>Aloha Raf,
>> Hey Jim-
>>   Just a quick comment on black-listing... I think Brian already
>>mentioned it in his blog post but there are MANY variations of the magic
>>number (range) so black-listing may be even tougher than updating the
>>JVM, in my humble opinion.
>> Rafał Łoś
>> InfoSec Specialist & Blogger
>> ________________________
>> On 2011-02-13 16:24:59 GMT James Manico <jim at manico.net> wrote:
>>> Hey Brian,
>>> I think it's critical that we discuss these issues with prescriptive
>>> remediation advice.
>>> 1) Update your JVM, often easier said then done
>>> 2) Build a blacklist filter looking for this specific numerical attack
>>> range. I already patched this in the ESAPI for Java security library
>>> which you will see in ESAPI 2.0 rc12 within a week or 2, but the
>>> credit goes to Adobe for being on top of this (and to Williams for
>>> pointing this out to me).
>>> http://blogs.adobe.com/asset/2011/02/year-of-the-snail.html
>>> I'm impressed team Adobe!
>>> -Jim Manico
>>> http://manico.net
>>> On Feb 12, 2011, at 10:13 PM, Brian Chess <brian at fortify.com> wrote:
>>>> There's a very interesting vulnerability in Java kicking around.  I
>>>> about it here:
>>>>   http://blog.fortify.com/blog/2011/02/08/Double-Trouble
>>>> In brief, you can send Java (and some versions of PHP) into an
>>>> loop if you can provide some malicious input that will be parsed as a
>>>> double-precision floating point number.
>>>> This code used to look like the beginnings of some decent input
>>>>    Double.parseDouble(request.getParameter("d"));
>>>> Now it's the gateway to an easy DOS attack.  (At least until you get
>>>> patch from your Java vendor, many of whom haven't released patches
>>>> Oracle has released a patch.  Do you have it?)
>>>> Until a few days ago, all major releases of Tomcat made matters worse
>>>> treating part of the Accept-Language header as a double.  In other
>>>> you don't need to have any double-precision values in *your* code for
>>>> app to be vulnerable.
>>>> The SC-L corner of the world puts a lot of emphasis on training and
>>>> looking for known categories of vulnerabilities.  That's all
>>>>goodness.  But 
>>>> this example highlights the fact that we have to build systems and
>>>> procedures that can quickly adapt to address new risks.
>>>> Brian
>>>> _______________________________________________
>>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org
>>>> List information, subscriptions, etc -
>>>> http://krvw.com/mailman/listinfo/sc-l
>>>> List charter available at -
>>>> SC-L is hosted and moderated by KRvW Associates, LLC
>>>> as a free, non-commercial service to the software security community.
>>>> Follow KRvW Associates on Twitter at:
>>>> _______________________________________________
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org
>>> List information, subscriptions, etc -
>>> List charter available at -
>>> SC-L is hosted and moderated by KRvW Associates, LLC
>>> as a free, non-commercial service to the software security community.
>>> Follow KRvW Associates on Twitter at:
>>> _______________________________________________
>The Web Security Mailing List
>WebSecurity RSS Feed
>Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>WASC on Twitter
>websecurity at lists.webappsec.org

More information about the websecurity mailing list