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 <j...@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 <br...@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 _______________________________________________
