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