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

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

I bet the whitelist is bigger :-) --Jeff On Feb 13, 2011, at 11:35 AM, Rafal Los <rafal@ishackingyou.com> wrote: > 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 >> _______________________________________________ >> > > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Am 13.02.2011 20:33, schrieb Jim Manico: > 1) Generation 1 WAF rule (reject one number only) hmm, this is not a Generation 1 WAF rule, but a (hot) virtual patch to be used 'til the proper WAF rule is ready, which is a whitelist approach Jim, I assume you just missed the right term ;-) (we see where a WAF performs better than code fixing; SCNR) Achim

Jim, As promised, here is an updated ModSecurity ruleset. with the use of the ModSecurity Lua API, we (myself and Josh Zatlin of PureHacking) came up with a new Generation 2 detection mechanism similar to what Brian Sullivan (Adobe) presented below. First step is to inspect the ARGS and REQUEST_HEADERS data using a regex to match on potential floating point payloads - SecRule ARGS|REQUEST_HEADERS "[0-9\.]{12,}e-[0-9]{3,}" "phase:2,t:none,t:lowercase,nolog,pass,exec:/usr/local/apache/conf/modsec_c urrent/base_rules/FloatingPointDoSAttack.lua" If a payload is found that matches the regex check, ModSecurity will execute an external Lua script. The lua script then extracts out payloads, strips out the "." and then searches for the MagicDoSNumber. If this is found, then a TX variable is exported - ################################# #!/opt/local/bin/lua function main() local Pattern = 2225073858507201; -- Get the ModSec collections local Headers = m.getvars("REQUEST_HEADERS"); local Args = m.getvars("ARGS"); for i = 1, #Headers do FilteredPattern,NumChanges=string.gsub(Headers[i].value, "[.]", "") if string.gmatch(FilteredPattern, Pattern) then m.setvar("tx.floatingpointdos", Headers[i].name) return ("Potential Floating Point DoS Attack via variable: " ..Headers[i].name .. "."); end end for i = 1, #Args do FilteredPattern,NumChanges=string.gsub(Args[i].value, "[.]", "") if string.gmatch(FilteredPattern, Pattern) then m.setvar("tx.floatingpointdos", Args[i].name) return ("Potential Floating Point DoS Attack via variable: " ..Args[i].name .. "."); end end return nil; end ################################# Then we have one follow-up rule that checks if the TX:FLOATINGPOINTDOS variable is set - SecRule TX:FLOATINGPOINTDOS ".*" "phase:2,t:none,log,block,msg:'Floating Point DoS Payload Found.',logdata:'Location: %{matched_var}',tag:'CVE-2010-4476'" We have conducted some tests with different payloads and this appears to work pretty well. If you find any issues please let me know. Cheers, Ryan On 2/13/11 2:33 PM, "Jim Manico" <jim@manico.net> wrote: >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 >>> _______________________________________________ >>> >> > > >_______________________________________________ >The Web Security Mailing List > >WebSecurity RSS Feed >http://www.webappsec.org/rss/websecurity.rss > >Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > >WASC on Twitter >http://twitter.com/wascupdates > >websecurity@lists.webappsec.org >http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.or >g