Re: Java DOS

[Shanahan Pete <pete () petesh com>]

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

-- 
Pete Shanahan  + 353 (87) 412 9576
If God is your co-pilot... switch seats

Attachment: smime.p7s
Description:

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