Re: Java DOS

[Chris Schmidt <chrisisbeef () gmail com>]

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