Re: [SC-L] Java DOS
On 02/15/2011 09:59 AM, Shanahan Pete wrote: All of the structures laying on top of the basic string-number parsing assume that the parsing works. If it's broken then repeatedly fixing the issue in frameworks is not going to address the issue, it is merely going to defer it. I completely agree. Unless you have some reason why you cannot fix the issue at the JVM it does not make sense to fix it at some other level. I suppose there may be cases where your JVM might be in an embedded consumer device where you can't require updates. In such cases, fixing this at the application layer might make sense as long as management understands (and they probably won't) that you are only fixing it in *your* particular application but that the root cause still remains. I am well aware that the upgrade of a JVM to fix a bug can have a substantial effect on the overall performance of the JVM. Changes between the 1.6.0_12 vm and the 1.6.0_22 vm do not just address bugs in the implementation, but actually add different garbage collectors and schedulers. These changes require extensive testing to ensure that they do not affect assumptions that existed prior to the upgrade. Oracle as made it pretty easy to address this particular issue with their fpupdater tool. All it does is update the java/lang/Double.class file in the rt.jar with a fixed version after first making a backup of your existing rt.jar. So the impact should really be minimal and if you've done things intelligently and only have a few JDK / JRE instances per server it should be a fairly easy fix. Plus, if something should go wrong, you can rollback to your previous rt.jar. This is no different an issue than the intel F00F bug, something that has to be dealt with, but which should not have us all throwing out everything claiming 'the sky is falling' (which is the impression I reach reading the messages) I don't believe that I, at least, happened to be overreacting and claiming that the sky was falling. In fact, I was ready to rank this as relatively low risk to my company until I found out about Tomcat using Double.parseDouble() to parse the 'quality' metric of the Accept-Language HTTP request header, thus making any application calling ServletRequest.getLocale() potentially exploitable without either the JVM or Tomcat patch. This was my whole point of asking the opinion of others about the exposure to this. My personal experience in almost 28 yrs of telecom IT as been that using floating point is relatively rare. I think I can count on one hand the number of times I've legitimately used a float or double in production code in all those years and during that time, I've written a lot of code. I was asking this though, in part, because most of my experience has been in systems programming rather than application development and did *not* want to be overreacting. I learned long, long ago that if everything is a major incident, then nothing is treated as a major incident. (I have a great NYEX story that others have told me along this line while I worked at Bell Labs, with great lessons learned, but I don't want to digress that much on this list.) The truth is that the sky has been falling since before we started working on systems, and it will continue to fall long after we are mouldering in the grave, we just have to deal with it. If you are referring to how systems have been failing since day one, then I'd agree. But if you are referring to how it is a universal reaction for everyone to overreact, I'd have to disagree. To me, the sky is falling is about the latter rather than the former. If the bug is in the float parser, where is the issue putting a trusted replacement in to deal with the issue? I can't see this as being much of a problem. The performance testing of which should not take more than a few hours (assuming testing infrastructure is in place). Oracle's fpupdater tool does just that--it replaces (only) the Double.class in the rt.jar. But the issue is the shear # of instances that have to be patched. Where I work, some environments have done things right (and use a common instances of JDKs--only one of each version) and other environments unfortunately have done things wrong, naively following he default WebLogic Server installs which each has its own JDK. Bottom line is that we conservatively have about 2000 JDKs on about 100 servers to patch in the environment that did it wrong. That takes some serious staff effort to get all those patched and then restart all the app servers all without incurring any downtime. you have -Xbootclasspath, and you also have java.endorsed.dirs, surely one of these will be able to deal with the issue? After a few minutes the VM optimized code will probably outperform any frontend parsing code. Once there is a generally accepted patch of this form, then I will happily deploy it to my systems. That would mean altering startup scripts which would take even longer than running the
Re: [SC-L] Java DOS
On 02/15/2011 11:38 AM, Jim Manico wrote:
[snip[
Ryan Barnett just spit out a new (impressive) mod security rule so you
can tactically patch without touching code (see below).
[snip]
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 -
Great idea, but the regex still needs work. For instance, one needn't
even use scientific notation at all, unless there is some other
mod_security rule restricting the overall length of an HTTP request
header. E.g.,
Accept-Language: en-us; q=0.0...00022250738585072012
where I've omitted the appropriate # of zeros for the sake of readability.
Similarly, one could also write the quality metric using 'e-90' or
'e-3' or whatever; even 'e+2' if I wanted. But the approach is correct;
only the regex needs work unless there's some other mod_security rule
that would catch these things.
-kevin
--
Kevin W. Wall
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents.-- Nathaniel Borenstein, co-creator of MIME
___
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
___
Re: [SC-L] Java DOS
I would assume just about any app with a shopping cart does. This is of course compounded by libraries like struts and spring mvc that autobind your form variables for you. Use a form with a double in it and your boned. Sent from my iPwn On Feb 14, 2011, at 8:57 AM, Wall, Kevin kevin.w...@qwest.com wrote: Jim Manico 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 Depending how when the exponent conversion is done, this mod_security rule may be completely ineffective. For example, if an attacker can write this floating point # as the equivalent 22.250738585072012e-309 (which note, I have not tested), then the test above is invalid. I presumed that this was why Adobe's blacklist *first* removed the decimal point. Adobe's blacklist could be generalized a bit to cover appropriate ranges with a regular expression, but I agree wholeheartedly with you that what you dubbed as the Chess Defense (I like it) is the best approach short of getting a fix from the vendor of your JRE. So on a somewhat related note, does anyone have any idea as to how common it is for application developers to call ServletRequest.getLocale() or ServletRequest.getLocales() for Tomcat applications? Just curious. I'm sure it's a lot more common than developers using double-precision floating point in their applications (with the possible exception within the scientific computing community). -kevin --- Kevin W. Wall Qwest Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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 ___
Re: [SC-L] Java DOS
On Feb 15, 2011, at 12:06 AM, Chris Schmidt chrisisb...@gmail.com wrote: On Feb 14, 2011, at 8:57 AM, Wall, Kevin kevin.w...@qwest.com wrote: [snip[ So on a somewhat related note, does anyone have any idea as to how common it is for application developers to call ServletRequest.getLocale() or ServletRequest.getLocales() for Tomcat applications? Just curious. I'm sure it's a lot more common than developers using double-precision floating point in their applications (with the possible exception within the scientific computing community). I would assume just about any app with a shopping cart does. This is of course compounded by libraries like struts and spring mvc that autobind your form variables for you. Use a form with a double in it and your boned. Good point about things like Spring and Struts. Hadn't thought of those cases. OTOH, if I were implementing a shopping cart, I'd write a special Currency class and there probably use Float.parseFloat() rather than Double.parseDouble() [unless I were a bank or otherwise had to compute interest], and hopefully Float does not have similar issues. -kevin -- Kevin W. Wall 614.215.4788 Qwest Risk Management / Information Security Team The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein, co-creator of MIME From: Chris Schmidt [chrisisb...@gmail.com] Sent: Tuesday, February 15, 2011 12:06 AM To: Wall, Kevin Cc: Jim Manico; Rafal Los; sc-l@securecoding.org Subject: Re: [SC-L] Java DOS This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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 ___
Re: [SC-L] Java DOS
Anger growing string - number. it breaks, deal with it, and move on. why is this a problem again? On 15 Feb 2011, at 05:06, Chris Schmidt wrote: I would assume just about any app with a shopping cart does. This is of course compounded by libraries like struts and spring mvc that autobind your form variables for you. Use a form with a double in it and your boned. Sent from my iPwn On Feb 14, 2011, at 8:57 AM, Wall, Kevin kevin.w...@qwest.com wrote: Jim Manico 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 Depending how when the exponent conversion is done, this mod_security rule may be completely ineffective. For example, if an attacker can write this floating point # as the equivalent 22.250738585072012e-309 (which note, I have not tested), then the test above is invalid. I presumed that this was why Adobe's blacklist *first* removed the decimal point. Adobe's blacklist could be generalized a bit to cover appropriate ranges with a regular expression, but I agree wholeheartedly with you that what you dubbed as the Chess Defense (I like it) is the best approach short of getting a fix from the vendor of your JRE. So on a somewhat related note, does anyone have any idea as to how common it is for application developers to call ServletRequest.getLocale() or ServletRequest.getLocales() for Tomcat applications? Just curious. I'm sure it's a lot more common than developers using double-precision floating point in their applications (with the possible exception within the scientific computing community). -kevin --- Kevin W. Wall Qwest Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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 ___ -- Pete Shanahan + 353 (87) 412 9576 Any problem in Computer Science can be solved by adding another layer of indirection smime.p7s Description: S/MIME cryptographic signature ___ 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 ___
Re: [SC-L] Java DOS
Jim Manico 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 Depending how when the exponent conversion is done, this mod_security rule may be completely ineffective. For example, if an attacker can write this floating point # as the equivalent 22.250738585072012e-309 (which note, I have not tested), then the test above is invalid. I presumed that this was why Adobe's blacklist *first* removed the decimal point. Adobe's blacklist could be generalized a bit to cover appropriate ranges with a regular expression, but I agree wholeheartedly with you that what you dubbed as the Chess Defense (I like it) is the best approach short of getting a fix from the vendor of your JRE. So on a somewhat related note, does anyone have any idea as to how common it is for application developers to call ServletRequest.getLocale() or ServletRequest.getLocales() for Tomcat applications? Just curious. I'm sure it's a lot more common than developers using double-precision floating point in their applications (with the possible exception within the scientific computing community). -kevin --- Kevin W. Wall Qwest Risk Mgmt / Information Security kevin.w...@qwest.comPhone: 614.215.4788 It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration - Edsger Dijkstra, How do we tell truths that matter? http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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 ___
Re: [SC-L] Java DOS
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 -
[SC-L] Java DOS
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 ___
