Oracle blocks security hole with quick, hot 'n' premature Java update Oracle has brought forward the timetable of an upcoming Java security update by two weeks in order to block off an in-the-wild security hole. The update, originally scheduled for 19 February, was released a fortnight early on Friday because of "active exploitation 'in the wild' of one of the vulnerabilities affecting the Java …
@DAM
Yeah, it's an utter ballache. Hypothetically it should silently install when invoked with /s, but that fails more often than not, usually with no helpful indication as to why in the logfile.
I'm at the point now where I grab the MSI file from %TEMP% and batch up a silent install routine that uses the GUID of previous versions to ensure that old versions don't remain in place. They claim that as of Update 11 the /STANDALONE switch will render this unnecessary, but I'll believe that when I see have repeatedly tested it.
(I'd be happy to get rid of the bastard thing altogether at this point, given that I got hit by the vuln over Christmas courtesy of a compromised advertising network serving ads on a forum I frequent - hours of misery trying to clean it up for experimental purposes, prior to giving up and restoring from a known clean image - , but happily for me we've just rolled out a new service which requires Java at the client. Deep joy...)
I can only point the commentariat to the Sophos post indicated in the original article before they make the usual noises. It clearly explains what's what. (More so than stuff that appeared in IEEE Computer Mag as I mentioned somewhat earlier.)
First the most obvious part; reputation. Back in the Sun days Java had a reputation of being secure, you could also see some "proof" of this due to several banks and financial institutions building their solutions based on Java SE and EE. Deserved or not is something I can't tell, it does strike me as odd that some current exploits also manage to target SE5 and the likes (which, in all honesty, was EOL'd before the Oracle invasion) but the fanboy in me (I'll be honest here) can't help wonder; most of those SE5 exploits target the latest 5u22 update. Is that still a pristine Sun release or has Oracle added some of their "cosmetic only" changes into it ?
I'd check this for myself weren't it for the fact that you can't download these versions any longer without an Oracle account. Needless to say; I don't have one, even demanded that they'd remove it (I did used to have a Sun / SunSolve account).
Now that reputation took a blow, which shouldn't be underestimated IMO. For many people in my surroundings Java used to be somewhat of a "vague environment" which "obviously was robust". Those opinions will clearly have shifted with Java exploits hitting global media.
But the second part could be much more dire: competition.
When taking a look at some of the competitors in the field you'll quickly notice that in some cases competitors provide solutions which can do the same by using far less code. Less code by definition also means quicker results, whether for good or worse. But which could very well make it suddenly much more appealing to jump ships.
Sure; this development has been going on for quite some time now, people even used to criticize Sun because they were very reluctant with adding specific new developments to the Java core engines.
But back then Java wasn't openly criticized in the media for being insecure and something people should be careful with. Would you tell your customers that "Our website was build on Java, robust as it can get!" in these days ? Not sure, but I don't think it'll have the positive effects you may have hoped for.
>which can do the same by using far less code. Less code by definition also means quicker results, whether for good or worse.
Without getting into the fallacy of less code means quicker results as a C++ developer I have seen plenty of quicker results end up costing a few orders of magnitude more in maintenance than development. I have also seen plenty of quicker results that were impossible to scale including even the en vogue at the time technology the solution was written on. Last of all, managed code has its place but its telling that Microsoft is moving away from managed code in their commercial products including Metro.
> Our website was build on Java, robust as it can get
And how do these exploits change this? Other than in the minds of people who do not understand what these exploits are and how they relate to the java platform.
These only affect applets, a tiny % of java , that technology that should have been forgotten about many years ago.
These only affect applets, a tiny % of java
Some have now been shown to permit remote exploitation of RMI servers as well. Having an open RMI server is pretty dumb, but it's no longer true that the recent bout of exploits is completely confined to applets (and other programs running in a restricted security context).
More generally, though, it's true that much of the wailing and teeth-gnashing is unnecessary, and the danger to most production Java systems is small to negligible.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
