Slashdot Mirror
Dangerous Java Flaw Threatens 'Virtually Everything'
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."
When I told them NoScript was a great plugin.
SmartBox
Okay, so which versions are vulnerable?
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.
Javascript + Nintendo DSi = DSiCade
I'd say borderlining FUD. What help is it to tell us that there's some huge security bug without telling us what it is?
One huge problem I see with this is that not only are users generally unaware of what JRE/JDK they're using, they may not even know that they're using one at all. Some software like to install their own JRE version, so a user might have three or more different versions spread around the system, which needs rooting out (I suggest "c:\>dir rt.jar /S" on windows machines)
Java != Javascript
If you're paranoid, at least disable the right thing.
Java != Javascript
How many times have we seen this comment...
--
The world is divided in two categories:
those with a loaded gun and those who dig. You dig.
Well, we have a gut feeling that there is a vulnerability...
The article has no information what so ever - but, perhaps that is to avoid spreading information on how to exploit this alleged weakness.
That's what makes it a joke, for all those who've actually read the license agreement. :-)
Lisp is traditionally garbage collected. I suppose you could modify a Lisp to operate without a GC, but you could probably modify Java the same way. Perhaps you're thinking of another language?
Commercial nuclear reactors, at least in the US, are controlled via relays, not integrated circuits. The control room for a nuclear plant looks a lot like the array of switches and dials on the spacecraft in the movie Apollo 13, scaled up to fill a large room. You might see some more modern technology used for recording or monitoring purposes, but the fundamental operations are not based on anything as unreliable as software.
I have seen the future, and it is inconvenient.
There is no single standard behavior for Lisp garbage collection, nor even really is "Lisp" a single language. It's a wild forest of various implementations and dialects, some of them confederated under the Common Lisp specification.
DNA just wants to be free...
No, it's not hype. Problems like this actually highlight Java's features all that much more.
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.
Javascript + Nintendo DSi = DSiCade
We note that this vulnerability happened in a C library that was used for processing images. There wasn't a buffer overflow in the Java portion because Java has no buffer overflows. It's in the C code where buffer overflows can lurk for years and years.
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.
You're right, it's not a tool's fault if people don't know how to use it. But C has been around a hell of a long time, and people have been making buffer overrun mistakes for the entire history of its existence, even those who should (and do!) know better, simply because unless it's the main thing on your mind when you're coding C it's an easy mistake to make. So I don't think it's likely that people will ever stop making these mistakes, regardless of education, because the language allows them (and to some extent encourages them).
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.
This is the first buffer overflow vulnerability Java has ever been found to have, AFAIK. And they announce it with "threatens nearly everything." Don't the buffer overflow vulnerabilities announced frequently about IE and other programs also threaten nearly everything?
"If Sun simply rewrote the code in Java (which wouldn't be hard; only time consuming"
Kevin Smith on Prince
I can't comprehend why people continue to use platforms without package management, or why there has never been a serious project to bring a package manager to these other platforms.
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.
Don't thank God, thank a doctor!