[WEB SECURITY] [SC-L] Java DOS

Rafal Los rafal at ishackingyou.com
Sun Feb 13 11:35:50 EST 2011


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





More information about the websecurity mailing list