'Silent but deadly' Java security update breaks legacy apps - dev An application developer reports that the latest Java 7 update "silently" deletes Java 6, breaking applications in the process. Java 7 update 11 was released two weeks ago to deal with an unpatched vulnerability which had gone mainstream with its incorporation into cybercrook toolkits such as the Blackhole Exploit Kit in the …
This post has been deleted by its author
You word it as though there were no choice but to stay on Java 6. That would be partly valid for a while if it was a customer, but this is a developer speaking.
The application does not require Java 6; it requires an update so it will work with Java 7.
The developer should update it.
As for customers stuck with lazy developers, after a period of time (say the time it takes for 11 releases to come out) they should start looking for new a vendor.
"but this is a developer speaking"
Yes, about a Java update that could get applied to a company without Java developers who run Java software: "several of their customers had updated their Java 7 and our customer’s product had stopped working"
Imagine, you're a small company, you've paid for an application to be developed and do not have in-house developers. You've been happily using said application for years when this update removes Java 6 and in an instant, your business grinds to a halt. The answer to that is not "QwitcherBitchin" as you seem to support.
If you'd developed that application, would you drop everything to update the application before the business goes bankrupt? I don't think so. Forcibly deleting an old version of something like Java is not a good idea given the known version dependence of Java applications. It's the equivalent of rolling an OS upgrade out without any prior testing.
Umm...
If you run Automatic Updates, that's pretty much EXACTLY what MS does with old versions of IE. To the point that it's a royal biatch to be able to compatibility test for multiple versions.
What messes you up is that MS also released hotfixes that took the updates off the patching list and users never undid the hotfixes. Possibly because they run software that still relies on those versions we all wish were dead.
"As for customers stuck with lazy developers, after a period of time (say the time it takes for 11 releases to come out) they should start looking for new a vendor."
I quite agree. Ironically, the big enterprise systems that we have that don't work with Java 7 and, for the foreseeable future seem to require Java 6, are produced and under active support by Oracle.
Yes, but I'm the lowly helpdesk dude at the bottom of the food chain. And somewhere up the food chain is somebody with what is effectively the force of law behind him saying we have to keep using the crap from that vendor. And no, it's not a minor program off in a basement office somewhere. Almost all the folks in the executive suite (or it would be the executive suite if it weren't government) have it (probably hate it too) and use it on a regular basis (at least once a week, with a fair number (more than 50%) living in the app).
This post has been deleted by its author
When you have a runtime environment that existing applications rely on, you have to back port fixes to it so you don't disrupt your customers. Either that or you have to always ensure backwards compatibility. One thing you don't do, is remove things at your whims and break functionality, even if you're going to stop maintaining the old version after time.
Otherwise, who would invest time and money building software using fragile environments?
This is what Microsoft does with their compiler runtimes (MS Visual C++, Visual Basic) and .Net Framework. They have to maintain several versions of these, if they are installed, because new versions are not drop-in, backwards compatible.
You evidently don't know much about software, but don't let that stop you from admonishing others.
@Dan Paul - read for comprehension!
The article specifically said the software works fine under java 7, simply that it has a pointer to the java executable, which got invalidated when the installer, for no good reason, removed java 6 which the software was pointing too. Solution was simple, but it had no reason to be necessary.
Oracle seems pretty clueless about how to manage products they didn't internally develop. You KNOW they're doing something wrong when you start looking wistfully at the days when sun was a bedraggled, drooling zombie, but at least it was STILL THERE.
I do distinctly remember having problems a couple of years ago running an app that did an RMI/IIOP connection to WebLogic Server 8.1 (which runs on J2EE 1.4) from a client running Java 6. Autoboxing breaks something server-side, as it tries to send a Boolean to a boolean. However, this can be fixed by simply doing
java -version:1.4 -jar MyClientApp.jar
which makes Java run in something akin to a compat mode. Of course, the problem referred to in this article isn't a compat issue, but more of the exe no longer being where the scripts expect them to be. I'd add that usually these out of place JRE/JDKs might have some extra libraries in lib/ext that aren't in the "updated" JRE, which might end up breaking the apps when they start using the new JRE...
@Daniel B.
"However, this can be fixed by simply doing
java -version:1.4 -jar MyClientApp.jar"
Nott quite. It causes the Java launcher to locate and use a1.4 JRE. This only works if one is installed and (obviously) will not work if the new installer has removed all old versions.
Please help me understand why Java and .NET really need so many damn versions and different libraries to begin with? Why should I have Dot Net 1.1, 2, 3.5 and 4
For example, when Version One gets superseded by Version Two, should not all of the previous parts of One be part of Version Two , just revised?????
No, that shit would just make too much sense.
Trouble is Java 7 isn't quite ready for prime time on the Mac. We need Java at work because the applications SAP provides for platforms other than Windows are written in Java, and many other businesses and large organisations are in the same situation. We also have internal business Java applications that use JOGL (the OpenGL API - JSR-231) while doesn't work on Java 7 on the Mac yet, which kills all 3D applications (and 3D games) that use Java. Now Java applets in web browsers are another matter, however in Scandinavia, where I live, many banks require Java for their net bank solutions as its used as part of the authentication project, so killing Java applets basically stops our net bank access from working (!). This basically risks leaving us reliant on running Windows on Parallels or VirtualBox in order to keep using our Macs...
Apple is not particularly friendly to other developers products.
If people want to get a Mac they should understand that and not make themselves dependent on other software.
There is a reason most companies use PCs. The code is more tested, more of the vulnerabilities have been found and fixed, but also it is far more open and accepting to third party apps and languages.
Trouble is Java 7 isn't quite ready for prime time on the Mac.
This. I can't believe just how broken Java 7 is on the Mac when it comes to UIs. Even sticking with plain old AWT and Swing, I find cases where <code>drawShape()</code> just doesn't, graphics contexts get flipped, images don't quite render correctly, etc. This is why I still have Java 6 on my MacBook.
And, yes, that does make me cringe. There are features in 7 I'd love to use in my code, but can't.
> Please help me understand why Java and .NET really need so many damn versions and different libraries to begin with? Why should I have Dot Net 1.1, 2, 3.5 and 4
Because API designers (especially those for the sprawling, monolithic frameworks that are the current de rigueur) don't seem to give a shite about backwards compatibility.
years ago, he commented on the difficulty in buying a record[1] ...
"Do you want the 12", the the extended 12", the club mix, the extended club mix, the club house mix, the 12" club house mix featuring Sir Skankalot, the dub house mix ....."
"Just give me the one where they got it right."
[1]Ask your parents. Or their parents.
WRONG, because then your software crashes if the user installs a version of Java you're not supporting yet.
Since Java specifically supports multiple versions being present, and lets customers clean up old ones as they retire apps needing older ones, Oracle had NO business doing this. Should you still be using apps dependent on java 6? Probably not, but that's not any of oracle's business.
Yeah, or finding out what java versions are installed and where from the Windows registry.
I once wrote a native Windows app that embedded Java installation. The first step I did was to read the installation path of the latest Java version from registry.
This is not Oracle's problem, rather it seems that the JNBridge product is just being lazy and it assumes it can find java from a fixed location.
As for Enterprise desktop apps, where tried and tested versions of all components are important, just bundle a preinstalled JRE with your product. Don't rely on the desktop JRE, which can be any version. Been there, done that also.
Can't speak for other firms and environments of course but it seems to me as if Java, as platform, is losing quite a bit of credibility with nonsense like this. Apart from being mentioned in mainstream media as having security issues (which in the days of Sun would have been described as a nightmare scenario since Sun really took great pride in keeping Java safe), the way things are being rolled out also leaves me with question marks.
Its good practice not to jump onto the latest bandwagon but sit it out for a while. Its also the main reason why my company still utilizes Java SE 6 and are looking into Java 7. But if you look at recent history then it seems only to have gone downhill when 7 got out.
Because not too long after its release date we started hearing stories about major flaws. And in the beginning those flaws only involved SE 7, like this one.
So I'm pretty sure that will make a lot of people wonder how feasible it really is to upgrade to 7. For a first major "Oracle release" I for one am not quite impressed with 7 so far. It has a good feature set, sure, but has also build up quite the legacy. Some people are tied into Java so to speak, so they'll just have to "go with the flow". But I can't help wonder how many people will eventually start looking for alternatives. That might even boost C# acceptance.
Looking at this from another angle, we have to thank Oracle. This is the same "fix" I've applied to all my home computing environment. Only I've taken it a bit further, simply removing the Java plugin, all versions, from all the installed browsers, fixes completely this and any future security issues Java may have.
I did the same a few years ago to fix the Windows security issues. I replaced it with Linux and since then I don't have to worry about these.
So thanks Oracle, for following the perfect example of how to deal with a product with a long history of security issues. Simply remove it. End of the problem.
(chorus follows trying to explain how they need Java for this and that and they cannot remove it from their browsers. Sorry folks, this is my home PC environment and enterprisey applications or banking contraptions written ten years ago don't apply)
Linux on the desktop is not popular, true, but Linux on the server most certainly is very popular. Desktop environments may have security vulnerabilities that aren't too well-documented or known, but most of the security vulnerabilities in the Linux and GNU subsystems themselves are quickly patched as soon as they're discovered. That said, recent versions of Windows can be configured to be nearly as secure as the Unix-based and Unix-like systems nowadays. Most security issues tend to be Trojan horses nowadays, no matter the platform.
@AC 17:19
Yeah, sure, that's how you can "fix" the problem on your home PC, but this article is about its impact on enterprise environments, not home PCs. You can't just remove software from or change functionality on an enterprise system without testing how it affects your workflow, unless you simply want to gamble your institution's ability to conduct business.
As I see it, you appear to have read an article about enterprise software, commented about your own home situation, and followed up with a clause in parentheses indicating that you don't care about enterprise software. Did I miss something?
"(chorus follows trying to explain how they need Java for this and that and they cannot remove it from their browsers. Sorry folks, this is my home PC environment and enterprisey applications or banking contraptions written ten years ago don't apply)"
If the Enterprise were no longer writing stuff in Java, I'd probably be out of work. *New* stuff is being made in Java. And Mexico's SAT (the taxman, that is) uses Java for sending in stuff, as everything you send is signed with a private key you register with SAT. The whole signing/validation thing is done by ... an applet. So disable Java, and you can't send your stuff to the taxman!
Oh, that app I'm talking about? Made in 2010.
2010 and they use an applet to sign and validate files sent to the server? How ironic, they surely have heard of SSL and certificates, but clearly they are not aware that the browser can authenticate and validate POST requests using browser installed certificates? Have they developed one of those lovely proprietary ActiveX/Windows-only "contraptions"?
Don't get me started on those government mandated things. And don't make it specific to Mexico. All over the world, there are many many examples of systems commissioned with public money that are simply terribly designed. We could make a "hall of shame" with examples all across the world.
According to the documentation from Oracle (last updated 27/11), which JNBridge also referenced in their blog, this behaviour is by design (Check out the FAQ section): http://www.oracle.com/technetwork/java/javase/documentation/autoupdate-1667051.html
"The Java auto-update process updates the latest version of Java on a user’s Windows machine. During the automatic update from JRE 6 to JRE 7, if a user only has one version of Java 6 the auto-update process will replace that JRE 6 with the latest version of JRE 7 leaving only JRE 7 in the system."
This begs the question; did someone miss the memo?
Anyway, what person in their right mind would ever choose to use Java Auto-Updates in an enterprise? It's near impossible to roll out a Java update in an enterprise environment without something breaking, so if you allow auto-updates (and I assume you also give your users admin rights since auto-updates needs this) you're bound to come a cropper very quickly.
@DJM
I *knew* I'd seen mention of this somewhere; my first reaction on reading this item was "hang on, isn't this feature mentioned explicitly in the JRE docs?"
Aside from which, if you've got an application (or are selling an application) which has explicitly defined version dependencies for runtimes, you should be telling your support team/customer base that this is important and explain why this means that they can't just patch to the latest release without testing or customising the install procedure.
I understand this makes life difficult for some folks (particularly smaller businesses), but its occurence demonstrates a failure in their processes. Given that the workaround is *gasp* reinstall the required JRE, I think that volubly complaining about a problem that only manifests due to either badly-documented software version dependencies or a support process that ignores said dependencies won't do anyone any favours. Certainly if I were a customer of a developer who did this, I'd be giving them the hairy eyeball and reconsidering future support agreements...
What would happen if Microsoft automatically removed .NET version 3 when the user installed a security update to .NET version 4?
They would (and have) include(d) .NET 4.0 functionality in .NET 4.5. And the .NET 3.5 component on Windows 8 and Server 2012 includes previous frameworks back to .NET 2.0.
It's a tough call for me. As much as I dislike Oracle, my experience says vendors should have tested with Java 7 twelve revisions ago (meaning back when it was in Beta). The same thing happened in the 5 -> 6 transition but I haven't found a Java 5 application that broke on 6, or wasn't addressed with a subsequent update to 6.
Oracle could have supported Java 6 indefinitely if they put the code support behind it. They just didn't want to. You can support any number of legacy products if you can be bothered (Windows XP) or not (virtually any consumer wireless router, it seems)
Even before JRE7u11 they had indicated that JRE6 updates would be run down.
http://www.loweslink.com/
Just check the requirements - it is very specific and I can't tell you how many times some helpful person upgraded from Java6u27 even after I disabled auto-upgrade because loweslink simply will not work with any other version. Lowes is a pretty big DIY company, you would think they would correct this but if wishes were horses, we'd all take a ride.
I keep a copy of java6u27 on my thumbdrive due to sneaky upgrades and the like.
;\
That's fine then.
Go tell management that they can't run Blackberry Enterprise Server any more (hint: the latest version of BESX requires some antediluvian version of Java 6).
Mind you, anyone who has browser plugins enabled on a server (or even runs a browser, for that matter) deserves everything they get.
I've tabled a motion to our dev team to consider removing Java as a client side requirement from our businesss app. Their response is that java is the only (free) tool that allows access to the client local path from the browser. So I guess we're stuck with it for the time being.
What would happen if Microsoft automatically removed .NET version 3 when the user installed a security update to .NET version 4?
I suppose that various .NET applications would become unstable or fail completely but, as that's expected behaviour for .NET applications, that's no big deal.
Does this company not do testing of their software? This should have been picked up and added to the support docs a long time ago.
The windows installer for java 1.7 runtime has for a long time removed java 1.6, I even mentioned that on here way back in August last year, when I pointed out the fix for a vulnerability that was being pushed also wanted to remove it.
Personally I think Oracle did this to try and kick start java 1.7 usage :-(
Hi guys -- I wrote the blog post that John (the article's author) cited. This is a great discussion. I just have a couple of comments on some of the comments here.
Our product does handle Java 7 (and 6, and 5, etc -- our stuff works with Java back to 1.3.1, although we'll probably move that up to Java 5 in the next release) just fine. But it's a tool that customers use to run and deploy their own software -- it allows .NET code to communicate with Java code. The Java runs in its own JVM, and the users get to choose whichever JRE they want -- it can be any version, it can be 32-bit or 64-bit. It can be be from just about any vendor. That's a good thing, because our users have their own environments, and it's their own business -- we don't dictate or judge. So, the problem isn't ours (we're not making people use Java 6, as some people say -- but our customers might choose to use Java 6), except that our customers' problems become our problems, and then we have to scramble. But it bothers me when we have to scramble to solve a problem that really wasn't caused by us, and which really shouldn't have been a problem to begin with.
Someone mentioned we should use the registry to choose the Java that we use. But that only tells us what Java is on the machine -- it doesn't tell us what Java the user wants or needs. Again, we let the user make that decision -- checking the registry won't tell us what we want to know. (Nor will JAVA_HOME, as someone else suggested.)
As for why any enterprise customer would allow auto-updates... the answer is that they shouldn't. But clearly it happens -- it happened to the customers of our customer. (Our customer is an ISV that uses our product. Their customers are the end users.) And when it happened, our customer heard about it from their customer, and called us, and we had to scramble, and the problem was easily corrected, but it shouldn't have been a problem in the first place, as someone mentioned.
As for the comment about why we don't supply the jvm.dll -- first because it should be up to our users to determine which version we need -- we can handle just about any one chosen and don't dictate. Second because jvm.dll doesn't work in isolation and we'd have to supply an entire private JRE -- it's much more than a single file.
Finally, I just want to point out that in our case, the problem is just the validity of a file path -- Java 6 and Java 7 reside in different places, and a single path won't work with both. However, this discussion has certainly come up with plenty of examples of Java software that works with Java 6 that simply won't work with Java 7.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
