websecurity@lists.webappsec.org

The Web Security Mailing List

View all threads

Re: [WEB SECURITY] [SC-L] Java DOS

JM
James Manico
Sun, Feb 13, 2011 12:23 AM

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@fortify.com wrote:

There's a very interesting vulnerability in Java kicking around.  I wrote 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 infinite 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 validation:
Double.parseDouble(request.getParameter("d"));
Now it's the gateway to an easy DOS attack.  (At least until you get a patch from your Java vendor, many of whom haven't released patches yet.  Oracle has released a patch.  Do you have it?)

Until a few days ago, all major releases of Tomcat made matters worse by treating part of the Accept-Language header as a double.  In other words, you don't need to have any double-precision values in your code for your app to be vulnerable.

The SC-L corner of the world puts a lot of emphasis on training and on 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@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates


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@fortify.com> wrote: > There's a very interesting vulnerability in Java kicking around. I wrote 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 infinite 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 validation: > Double.parseDouble(request.getParameter("d")); > Now it's the gateway to an easy DOS attack. (At least until you get a patch from your Java vendor, many of whom haven't released patches yet. Oracle has released a patch. Do you have it?) > > Until a few days ago, all major releases of Tomcat made matters worse by treating part of the Accept-Language header as a double. In other words, you don't need to have any double-precision values in *your* code for your app to be vulnerable. > > The SC-L corner of the world puts a lot of emphasis on training and on 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@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates > _______________________________________________