Re: Java DOS

[Chris Schmidt <chrisisbeef () gmail com>]

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
_______________________________________________