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.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.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 >>> _______________________________________________ > -- Pete Shanahan + 353 (87) 412 9576 If God is your co-pilot... switch seats
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 _______________________________________________
