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."
And people called me paranoid (Score:4, Insightful)
How...useful. :/ (Score:5, Insightful)
Okay, so which versions are vulnerable?
Extraordinary claims require extraordinary proof (Score:5, Insightful)
No offsense, but that's a rather incredible claim. They're saying that no matter if you're running a JVM on the server, cell phone, applet, desktop, or just about any other environment, you're vulnerable? I'm sorry, I can't accept that without extraordinary proof to back up such extraordinary claims.
Java was designed from the beginning with security in mind. Its security infrastructure has been tested for over a decade now. Any and all exploits have always been a flaw in the specific JVM or interface between the JVM and the OS. (Something which has been plauging browsers and other network-aware applications.) Now some security expert is saying that it doesn't matter what you're doing because Java as a whole is flawed?
It seems more likely to me that they're blowing the whole thing out of proportion and thereby spreading FUD. It's more likely that it's yet another security hole in specific JVMs and someone here is expanding that to all of Java. I'll happily look at the evidence to the contrary as soon as it becomes available.
Oh, and upgrades for Desktops is not too big of a deal. Java currently includes an autoupdater that should take care of the issue. All that's left is to deploy updates to servers, should these fellows actually prove that the language you're using somehow conveys a serious security through port 80.
TFA is extremely vague (Score:5, Insightful)
One Huge Problem (Score:3, Insightful)
Re:Simplest solution to this and all future bugs (Score:2, Insightful)
If you're paranoid, at least disable the right thing.
Re:Simplest solution to this and all future bugs (Score:2, Insightful)
How many times have we seen this comment...
Sounds like a warning from 'Homeland Security' (Score:3, Insightful)
The article has no information what so ever - but, perhaps that is to avoid spreading information on how to exploit this alleged weakness.
I know. (Score:4, Insightful)
Re:You forget... (Score:5, Insightful)
Re:You forget... (Score:5, Insightful)
Re:You forget... (Score:5, Insightful)
Re:Original AusCERT (Score:5, Insightful)
The problem in this case is that Sun used a native library to do the image parsing rather than writing a pure-Java equivalent. This shortcut ended up being a costly mistake that has resulted in a variety of holes caused by that library. If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming), the problems would go away.
This shows how secure Java is (Score:0, Insightful)
They should be looking at all these areas and trying to move to all-Java implementations for as much of the code as possible. And yes, it should be possible to write a Java implementation of a JPEG encoder and have it run as fast as the C implementation.
Re:You forget... (Score:3, Insightful)
Re:It's a C/C++ flaw in the Java environment. (Score:5, Insightful)
Would you really suggest that it's better to train people to not cut their fingers off using table saws than to get them to switch to table saws with some sort of finger guard? Yeah, it's not that the unprotected ones are at fault if you slip up and slice your pinky off, but it seems perfectly reasonable to avoid the problem altogether with a little prior consideration at the tool level, especially if the extra safety modifications are easy. Though to be fair, in this case I don't know what the "best" alternative to C is, since most of the real popular languages these days are interpreted either entirely or at a byte-code level, so are somewhat slow.
Blown out of proportion (Score:2, Insightful)
Re:Original AusCERT (Score:2, Insightful)
"If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming"
You're right, I can't... (Score:3, Insightful)
If it was a large office full of, say, Linux desktops, which ran a nightly update off some repository stored in the office, then you just update that repository. If it breaks something, you roll back, or roll out a new patch to fix what it broke.
Maybe not easy, but certainly no harder than rolling out patches to a small or medium-sized office.