Re: Java DOS

[Rafal Los <rafal () ishackingyou com>]

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 () 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 () 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
> > _______________________________________________
>
> _______________________________________________
> 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
> _______________________________________________


_______________________________________________
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
_______________________________________________