Rafal, 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 range) 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 Chess) 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 2.2250738585072014E-308 Reference: via email direct from Brian Chess _*Dr.*_ Chess, I'm very impressed. Aloha Raf, Jim > 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 _______________________________________________
