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 _______________________________________________
