CF911: Have you updated your #ColdFusion JVM to _24 yet? Important security fix for CF 8/9
Both CF 9.0 and 9.01 run on older JVMs (and therefore need this update). And are you on CF8? You're not left out: Adobe even has confirmed this update can be applied to CF 8 and 8.01, too!
Update 1: Since I wrote this blog entry in Oct 2011, Adobe has since come out with a new technote in Oct 2012 saying that you are now permitted to update to any version of Java 1.6 (for CF 8/9/10). Support for Java 1.7 is still not authorized.
Update 2: Since posting this note, I've realized I should document an important fact to be aware of if you DO update the JVM: after doing so, it may seem that changes you made to allow CFHTTP calls to SSL pages (or other tags in CFML that talk via SSL or TLS) may "seem to have been lost". The issue is that likely modified your current CF setup to import specific certificates for such sites, and those changes are "lost" on the JVM change in taht CF is now using a new JVM (and keystore), but these can be recovered. For more on that, see the next to last section below.
Old news, but not everyone knows
Someone mentioned today on a list that they'd seen news from Oracle of this important bug (and fix) for the JVM, which can cause someone to crash the JVM using a particular URL string. He also noted that while Oracle had released the fix some months ago, he lamented that "This issue doesn't seem to have gotten too much interest from Adobe."
I explained that in fact Adobe had addressed it, also some months ago.
Adobe's response
Adobe offered a technote on the issue in March 2011.
In fact, they not only confirmed support for (and recommended updating to) the fixed JVM version, 1.6.0_24, but they even (for the first time in years) approved updating to this JVM version for CF 8 and 8.01. Since those ran on very old JVM releases, which had problems not fixed until JVM update 10, this was really good news.
But as his note conveys, word just had not gotten out as much as it could. Beside his thread on that list, I hope now that this blog entry will help reach more people.
More about the bug
If you want to know more about the bug from a CF perspective, check out this blog entry (from several months ago by David Stockton, of cfconsultant.com). He explains the problem/risk as well as shows how to cause the problem (to confirm when it's fixed), as well as some useful extra info on using FusionReactor to help diagnose it.
How to update the JVM for CF
So if you're now persuaded, you may wonder how you go about updating the JVM. You may fear it's like doing open-heart surgery. It's more like getting a mole removed. :-) It could go wrong, but will barely be noticeable if done right.
There are many blog entries that walk through the few simple steps. Find out more from Ryan Stille, Mark Kruger, and Adobe, to name just a few.
While it's not too hard to do, there are just a couple of potential gotchas: be sure to get the JDK not the JRE, and pay attention to the special path format that's needed when pointing to the JVM on Windows.
So if you're on CF and have not yet updated the JVM, seriously consider it.
Any potential compatibility problems with updating the JVM?
Since Adobe has given this update its blessing, we can assume that there should be no code compatibility issues. Of course, whenever you change the JVM you are changing the heart of the CFML engine, and there may well be changes between the version you're running and the version you upgrade to. Besides reading any technotes from Oracle/Sun, you should also keep an ear out in the community for any issues that people spot.
Indeed, since originally posting this entry, I realized that one potential issue is not so much due to any "change in behavior between JVM versions" but rather due simply to the fact that by changing what JVM CF is using, you're also inherently changing where it looks for certain information--which you may have updated yourself.
In brief, if you previously updated the java keystore (within CF) to enable you to do CFHTTP or similar tags to call an SSL page whose certificate CF/the JVM did not recognize, you will find these now "break" again, as if your changes were "list". What it is is that you (or someone at your site) did steps to import such needed new certificate into CF's keystore, but now on changing the JVM that CF uses, that will cause CF to instead use that new JVM's keystore. There are a couple of different solutions to this (import them again, export them from the old store and import again, point the new jvm at the old keystore, etc.), which I'll elaborate in the other blog entry.
What about updates beyond u24?
This is an update since I posted the entry above. As you'll see in the comments below, some folks were kind enough to write in and point out that there have been JVM updates since u24.I did realize that, and do appreciate their wanting to share the info. I'd not mentioned updates beyond 24 simply because I would not propose (myself) that anyone now update beyond the release for which Adobe has certified CF. (At least not until compelling reasons arise and substantial community testing suggests it may be safe, as happened with CF8 and the u10 update. Even then, you are risking being out of bounds for support by Adobe, so should make such a change with caution.)
The whole point of this entry was that u24 HAD in fact received Adobe's blessing, for CF 8 and 9, which was pretty compelling and seemed to have been missed by some when it happened earlier in the year.
Finally, since I wrote this note, again Adobe has now given their blessing to any update of JVM 1.6 for CF 8/9/10. More at this technote.
One other thing I'll mention (shameless plug) is that the paid version of http://HackMyCF.com can notify you if your server JVM needs to be updated, among other things.
So while one can certainly take their chances on a later update, you're doing just that: taking a chance. As you've discussed, some may find that it works, others that something does not. Adobe is only saying (at least for now) that u24 is supported: nothing more.
I won't speculate myself on whether later ones can work. Others can, but I appreciate that there can be many variables that influence what may or may not work. So those wanting to play it safe should stick to u24 until told otherwise by Adobe, or perhaps as persuaded by substantial evidence from community experience. :-)
You do go on to mention Java 7, and sure, as I commented to others above, sure, I do realize there are later updates to 6, and yes, I realize 7 is out now.
As I said to them, I would not propose (myself) that anyone now update to Java 7. I see no compelling need to (and many who consider it seem often to be doing so to solve problems, which from my experience may be solved in other ways.) More than that, Adobe has not yet certified CF for any update beyond u24, and that was the real point of my entry here.
Anyway, in case anyone may find it hard to locate the older updates on the Oracle site, here is a link (which works, at least, for now):
http://www.oracle.co...
And just to save others the time from wanting to write in (though I appreciate the suggestions) I will update the entry to make clear my stance on later JVM updates beyond 24.
Other than this testing, I haven't upgraded any other servers up to 1.6.0_26... but I also haven't had any issues with it (even if it's unapproved/untested.)
I was just curious as to what your personal experience was with upgrading CF8/9 beyond what Adobe has tested. Do you know of anyone else who has done this? I'm not looking for an official Adobe-answer as much as real-world experience.
Do you have any idea what version Zeus will be using? (Or is that a FAQTCYBA?)
As for the image issue, if you ever find where you saw that documented, feel free to leave a link here for any who may be interested. Thanks.
http://www.oracle.co...
There, it indicates that the fixes are different between them, and it even offers a table at the bottom to help clarify which things apply to which JVM.
And the broader "Oracle Critical Patch Update Advisory - October 2011" (http://www.oracle.co..., applying to all products, not just JVMs) says specifically:
"Starting with the October 2011 Critical Patch Update, security vulnerability fixes for Oracle JRockit will be announced with the Oracle Java SE Critical Patch Updates. Java SE Critical Patch Updates are released on a different schedule but coincides with October's Oracle Critical Patch Update."
So good timing on your question. Seems we have that answer now.
First, to be clear, you could easily revert back to the old JVM if you wanted to. All the resources that showed how to change it made it clear that it was just a single line change in the jvm.config, where you pointed to the new jvm location in the java.home. If you saved the previous value as a comment, you can revert it. If not, the resources can help you sort out what the default should be for your deployment.
Second, and perhaps better, you can easily change this prompting behavior. More on that in a moment.
So yes when you install a JVM manually, you will indeed now get the prompts from the Java installation that's by default always checking to see if you've updated to the latest and greatest. They figure you'd always want that. But you're right that in our case, with a tool relying on it (but not yet certified for later updates), we may not want to.
So here's the simple fix (on Windows, any edition): go into the Control Panel, select Java. In the window that opens, choose the "update" tab, and deselect "check for updates automatically".
You could also choose the "advanced" button next to it, and change from the "weekly" to "monthly" prompts.
Of course, it's an interesting challenge that this leaves: if we don't get updated of new JVM updates, might we miss something critical? Yes, but if this is a machine which is used primarily for CF, then you're at least better off for having updated to u24, and stopped there, than to have done none of this and still be at the original jvm version that CF came with.
You could then keep your ear out (from Adobe, via their security update announcements) for if and when CF is certified for any later (truly critical) update. We can't expect Adobe to certify CF for every JVM update. It's just too much work to test, when you consider the exponential number of combinations of OSs and their versions, DB drivers and their versions, web servers and their versions, and so on.
Does that help? I certainly wasn't trying to "steer you wrong", in promoting here the JVM update that Adobe recommended. It was critical and needed.
But you raised a good question about how to deal with the update nags, and I hope this explanation helps you and others. Let me know what you think.
Your right, it is a CF server exclusively, so I'll trust that my RSS feeds to your blog and Pete Freitag's blog (and Ray and Ben and Ben and all the others) will keep me up to date on any critical issues from Adobe.
I was offering it respond to your last sentence: "I liked it better when it just ran in the background with CF." I wanted to make sure you (or other readers) understood that you could always go back. I was reading it like you felt like you'd now gone down a road where you couldn't go back.
But yes, as for keeping an ear out for updates, besides our feeds, there's an even better service that focuses solely on notifying you of such critical updates. John Mason maintains several "CF Updates and Patches RSS feeds" (http://www.codfusion...).
I list it among various tools to help with hotfix management in CF, as a relatively new category on my CF411 site: http://www.cf411.com...
Hope that helps. (And thanks for asking about the above, I think it's a useful addition to the blog entry.)
http://www.coldfusio...
which suggests that a new JVM arg is needed to get past a problem fixed by Java update 1.6.0.19:
-Dsun.security.ssl.allowUnsafeRenegotiation=true
This opens back up a hole that u19 was fixing, but until there's some better resolution to the problem, I wanted to pass it along. If I learn any more, I'll add a new comment here.
https://blogs.oracle...
Know that you can't really do anything regarding it, but just documenting it if anyone wants to get to the information.