Re: Java DOS

["Kevin W. Wall" <kevin.w.wall () gmail com>]

On 02/15/2011 09: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 completely agree. Unless you have some reason why you cannot fix
the issue at the JVM it does not make sense to fix it at some other
level. I suppose there may be cases where your JVM might be in an
embedded consumer device where you can't require updates. In such cases,
fixing this at the application layer might make sense as long as management
understands (and they probably won't) that you are only fixing it in *your*
particular application but that the root cause still remains.

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

Oracle as made it pretty easy to address this particular issue with
their fpupdater tool. All it does is update the java/lang/Double.class
file in the rt.jar with a fixed version after first making a backup of
your existing rt.jar. So the impact should really be minimal and if
you've done things intelligently and only have a few JDK / JRE instances
per server it should be a fairly easy fix. Plus, if something should
go wrong, you can rollback to your previous rt.jar.

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

I don't believe that I, at least, happened to be overreacting and
claiming that the sky was falling. In fact, I was ready to rank this
as relatively low risk to my company until I found out about Tomcat
using Double.parseDouble() to parse the 'quality' metric of the
Accept-Language HTTP request header, thus making any application calling
ServletRequest.getLocale() potentially exploitable without either the
JVM or Tomcat patch.

This was my whole point of asking the opinion of others about the
exposure to this. My personal experience in almost 28 yrs of telecom IT
as been that using floating point is relatively rare. I think I can count
on one hand the number of times I've legitimately used a float or double
in production code in all those years and during that time, I've written
a lot of code.  I was asking this though, in part, because most of my
experience has been in systems programming rather than application
development and did *not* want to be overreacting. I learned long,
long ago that if everything is a major incident, then nothing is treated
as a major incident. (I have a great NYEX story that others have
told me along this line while I worked at Bell Labs, with great lessons
learned, but I don't want to digress that much on this list.)

> 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 you are referring to how systems have been failing since day one,
then I'd agree. But if you are referring to how it is a universal
reaction for everyone to overreact, I'd have to disagree. To me,
"the sky is falling" is about the latter rather than the former.

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

Oracle's fpupdater tool does just that--it replaces (only) the Double.class
in the rt.jar. But the "issue" is the shear # of instances that have to be
patched. Where I work, some environments have done things right (and use
a common instances of JDKs--only one of each version) and other environments
unfortunately have done things wrong, naively following he default
WebLogic Server installs which each has its own JDK. Bottom line is that
we conservatively have about 2000 JDKs on about 100 servers to patch in
the environment that did it wrong. That takes some serious staff effort
to get all those patched and then restart all the app servers all without
incurring any downtime.

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

That would mean altering startup scripts which would take even longer than
running the fpupdater tool. Not all the startup scripts that would need
modified are identical so a script to modify the scripts might be
difficult. Fortunately, with the fpupdater tool this tact shouldn't be
necessary.

> I have to go through a large amount of security issues every day,
> trying to decide which ones were relevant in which are irrelevant.

Exactly what I am trying to do.

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

If you have not already looked at it, check out Oracle's fpupdater tool.
http://www.oracle.com/technetwork/java/javase/fpupdater-tool-readme-305936.html

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

The ramifications of a successful exploit make it too serious
to ignore. You do so at your own peril. But as you point out,
over reacting is also not the way to go.

> I don't ignore things; I deal with them, quickly, and without fuss

Generally I find how quickly that these things can be dealt with
is a function of size and bureaucracy.

> And then I get on to important things,
>
> like writing software ;)

:)

-kevin
--
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
_______________________________________________
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
_______________________________________________