Dangerous Java Flaw Threatens 'Virtually Everything' 323
Marc Nathoni writes with a ZDet article about a critically dangerous hole in the Java Runtime Environment. Due to the ubiquitousness of Java, this could prove a serious security problem. "Australia's Computer Emergency Response Team (AusCERT) analyst, Robert Lowe, warned that anyone using the Java Runtime Environment or Java Development Kit is at risk. 'Delivery of exploits in this manner is attractive to attackers because even though the browser may be fully patched, some people neglect to also patch programs invoked by browsers to render specific types of content,' said Lowe."
Re:You forget... (Score:5, Interesting)
And how? (Score:4, Interesting)
WARNING! WARNING! WARNING! WARNING! WARNING!
Wouldn't you just roll it out the same as with any other patch?
Without any more information and judging from comments such as that, I'm going to say that this "threat" will soon be found to be nothing. Just more Internet hype from someone trying to make a name for himself.
here is the security flaw (Score:3, Interesting)
http://groups.google.com/group/ph4nt0m/msg/05b113
Re:Original AusCERT (Score:2, Interesting)
TFA tells us "Virtually nothing" (Score:3, Interesting)
Re:not FUD (Score:4, Interesting)
Of course it's serious. That doesn't mean that it affects everything from mobile devices to servers! That was just plain FUD on the part of the article. They made it sound like every implementation of Java ever was now vulnerable and there is nothing we can do about it. In reality, it's a serious problem, but far less so than advertised. In fact, nearly all desktops should be updated by now thanks to the Java autoupdater.
Oh, don't start. I've written plenty of image and datafile loading routines in Java. You don't get nice "struct" features* for memory management, but that doesn't materially impact the ability to load and parse the data. The biggest thing to remember is that some formats use endians in something other than network order. (I'm looking at you Ronald Rivest! Do you know how much it would have saved me if MD5 used the same byte order as every other RFC under the sun? Grr...)
* I did write a proof-of-concept "struct" pre-processor once in an attempt to make a colleague happier. It basically added a new form of class type other than "class" and "interface". When parsed, it would be transformed into a ByteBuffer object with getX()/setX() accessors/mutators that accessed the correct locations of the buffer.
Re:You're right, I can't... (Score:2, Interesting)
The physical roll-out of the patch isn't necessarily a problem, although it could be.
For Java there are likely to be a minimal number of applications on desktops, and Java backwards compatibility tends to be both very good, and also predictable. So testing on the new VM should mitigate most of the risks and it should be fairly straightforward as an upgrade.
Where it's something like VB in Windows, an upgrade can break a hell of a lot of stuff. And if there are multiple user types in the organisation, each will have their own set of applications. The interdependencies can get very complicated, and you need to test every combination. Even if you only do high level regression testing, if that's needed across 70 different applications, with a dozen ways they may be combined on a desktop, that's a significant labour and management overhead. And those teams tend to be under-resourced and over-committed already..
I mentioned that physical roll-out can be complicated. Just three years ago an organisation I worked for had around 1200 retail outlets. They shared the same pipe into head office, and all had just 56kbps burst (28k committed) lines into the outlets themselves. A roll-out to update each of the half dozen PCs in all of the outlets physically couldn't complete in a single night.
Things just aren't as simple when you go multi-site, multi-configuration, multi-platform and refuse to spend the money needed to make it easy.