Secure Coding mailing list archives
Re: Java DOS
From: Chris Schmidt <chrisisbeef () gmail com>
Date: Tue, 15 Feb 2011 08:06:33 -0700
Pete -This is absolutely the right approach to this problem! A lot of people simply leave it at what your initial reply said though, without the elaboration that you call out here. That was the point of my message - and it is a common problem in our market. The same thing happened less than a year ago with the xml entity expansion bug - people said, "Just deal with it" without elaboration and outlining mitigation strategies and it resulted in nothing getting done quickly.
Your analysis here is spot on and I applaud your response. Thanks! On 2/15/2011 7: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 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. 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) 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 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). 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. I have to go through a large amount of security issues every day, trying to decide which ones were relevant in which are irrelevant. This issue is definitely relevant, based on our code, but I'm not going to perform a JVMectomy this close to release; and unfortunately, it's always close to release; just to address the issue. So what will I do? I'll probably replace the parsing code; using a drop-in class replacement. This seems like the most appropriate fix for this issue until the JVM catches up. And I'll probably have a good night's sleep tonight. What I won't do is ignore it, That was not the point of my message, I don't ignore things; I deal with them, quickly, and without fuss And then I get on to important things, like writing software ;) On 15 Feb 2011, at 14:02, Chris Schmidt wrote:I'm sorry to call you out on this one Pete - however, this is the exact attitude that ensures that things don't just get *dealt with*. How does the enterprise shop, using Spring or Struts just deal with this problem? A) Patch the JVM - usually not an option as something that can just be done. Enterprise developers and architects cringe at the thought of upgrading even there dependencies out of cycle. This requires a plan and a great deal of testing and competes heavily against the need for the developers and testers to be working on business code. It will generally be *scheduled* for some later time. B) Patch the MVC Framework - if indeed there is a patch to apply, which I don't know of yet. This is just as frightening to a dev shop as just patching the JVM, and even more so in some cases. The chances that Apache or Springsource would release a patch that could be applied to *every* version of their framework without requiring a full upgrade to the latest release version are so slim that they are not even worth considering. Now as a dev I have to upgrade the MVC framework my entire application is built on, which requires a great deal of planning and testing if it is even a possibility at all. There are still a very high number of legacy struts users out there - and upgrading from struts 1 to struts 2 is not an easy task. C) Manually Path the MVC Framework - Better than the above in terms of getting it dealt with, however - now I am out of sync with the release version of my MVC framework and I need to "remember" to reapply my patch for upgrades beyond that - or keep one of the existing solution paths in process. As you can see, if you are an enterprise development department, none of these options sounds especially good... D) Deploy a SWAF or WAF in front of your webapp, or if you have one add a rule to detect the attack. This is a good step one, but relies on a blacklist approach and as we all know all to well - blacklisting is *not* the way to defeat bad input. It is only a matter of time before a means to bypass the WAF rules are in place To address your second question - "why is this still a problem?" The answer is simple - most applications in the real world are large and complex things. This is a *low-level* issue and as such, the effects ripple out through the entire architecture of the system and it's subsystems. If you drop a pebble into the center of a complex network of interconnected puddles the ripples from that pebble impacting the water will spread through each puddle in the network - this is no different. Low level problems are difficult for enterprise applications to address because of the very nature of the problem. On 2/15/2011 6:36 AM, Shanahan Pete wrote: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.Wall () 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/35734652652093441Depending 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.Wall () qwest com Phone: 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 _______________________________________________
_______________________________________________ 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:
- Re: Java DOS, (continued)
- Re: Java DOS Jeffrey Walton (Feb 13)
- 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)
- Re: Java DOS Kevin W. Wall (Feb 16)