Secure Coding mailing list archives
Re: Java DOS
From: Jim Manico <jim () manico net>
Date: Sun, 13 Feb 2011 19:33:46 +0000
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 <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 _______________________________________________
Current thread:
- Java DOS Brian Chess (Feb 12)
- Re: Java DOS James Manico (Feb 12)
- Re: Java DOS Jeffrey Walton (Feb 13)
- <Possible follow-ups>
- Re: Java DOS Rafal Los (Feb 13)
- Re: Java DOS Jim Manico (Feb 13)
- Re: Java DOS Wall, Kevin (Feb 14)
- Re: Java DOS Chris Schmidt (Feb 15)
- Re: Java DOS Wall, Kevin (Feb 15)
- Re: Java DOS Wall, Kevin (Feb 15)
- Re: Java DOS Shanahan Pete (Feb 15)
- Re: Java DOS Chris Schmidt (Feb 15)
- Re: Java DOS Shanahan Pete (Feb 15)
- Re: Java DOS Chris Schmidt (Feb 15)
- Re: Java DOS Kevin W. Wall (Feb 16)
- Re: Java DOS Jim Manico (Feb 13)
- Re: Java DOS Jim Manico (Feb 15)