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?
The article contains virtually no information about the exploit. "There's a vulnerability. And it's really scary" is about all I got out of this.
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?
What about the people using it to run nuclear reactors?
For an additional undetermined sum, Pure Hacking will offer an ambiguous and nefarious fix for the vulnerability.
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.
I'm pretty sure this is it:
1 63fb0cc55
http://groups.google.com/group/ph4nt0m/msg/05b113
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.
This CNET article has more information. There is a vulnerability report at Sun. It is fixed in JDK and JRE 5.0 Update 10 or later, SDK and JRE 1.4.2_13 or later and SDK and JRE 1.3.1_19 or later.
>>Due to the ubiquitousness of Java, this could prove a serious security problem.
Ah! That would be 'ubiquity' then?
FFS editors!
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.
It looks like AusCERT has published on their page about this:
- 2007-2788
- 2007-2789
Quoted from
AL-2007.0071 -- [Win][Linux][Solaris] -- Sun Java Runtime Environment vulnerability allows remote compromise
1. Impact
A buffer overflow vulnerability in the image parsing code in the Java
Runtime Environment may allow an untrusted applet or application to
elevate its privileges. For example, an applet may grant itself
permissions to read and write local files or execute local
applications that are accessible to the user running the untrusted
applet.
A second vulnerability may allow an untrusted applet or application to
cause the Java Virtual Machine to hang.
Sun acknowledges, with thanks, Chris Evans of the Google Security
Team, for bringing these issues to our attention.
These issues are also referenced in the following documents:
CVE-2007-2788 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
CVE-2007-2789 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
That last line should read, "serious security risk through port 80."
I find it interesting that this team is supposedly reporting a major flaw, yet manually running the Java updater finds no new JVM versions to download. Didn't they contact Sun first? Shouldn't there be a patch already? Meh. The whole thing stinks.
If you want to run the updater yourself, you can either right-click on the Java icon in your taskbar and select "Control Panel", or you can run the "javacpl.exe" file in the "c:\Program Files\Java\jre\bin" directory. Look under the "Update" tab to see the update schedule. Click "Update Now" to check for the lastest release.
Mac users do not need to access a separate updater. Java updates are pushed through the standard system updates, accessible through the control panel. These are also scheduled to run on a regular basis. Only Linux/Unix users should need to manually update their JVMs if and when a patch becomes available. Some of these OSes do have a Java updater, but I don't know the current details about these.
Javascript + Nintendo DSi = DSiCade
That was yet another serious Java bug. Unless they've decided to review a story from January, which I guess is always possible.
Friday the 13th is the new April Fool's Day!
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.
...at least we can be assured whatever disaster happens, it will happen slowly. Just kidding!
That's what makes it a joke, for all those who've actually read the license agreement. :-)
This issue (I'll provide a link to the AusCERT page as the summary neglected to) was first publically announced on June 4 and fully patched by June 29th. All that's happened recently is some minor updates to the ticket. Yes it's serious, but anyone paying attention to such things will have patched already.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
It's fixed in:
* JDK and JRE 6 Update 1 or later
* JDK and JRE 5.0 Update 11 or later
* SDK and JRE 1.4.2_15 and later
From:
http://www.auscert.org.au/render.html?it=7664
Things you think are in the Constitution, but are not.
I see at the top where they mention the Google security team. But the article quotes only someone named Chris Gatford from "penetration testing firm Pure Hacking" and someone from "Australia's Computer Emergency Response Team"
AUSCERT ^ has issued something on this, but there is not many details. They claim the exploit is the ability for applets to escalate privileges.
Also, someone asked, but here are the versions they claim are vulnerable, for windows and solaris.
And a link to the Aussie security alert
FAQs are evil.
Just because you are paranoid doesn't mean there isn't an invisible demon out to eat your face.
Among other things, it has been confirmed that cellphones, computers, handhelds, iPods, small children, toasters, garage door openers and SUV owners are all vulnerable to this flaw.
The only device that isn't vulnerable to this is the Nintendo Wii. The theory is that the swinging of Wiimotes manages to sling the problematic code away from your device.
If you think that your computer might be at risk, pick it up and start spinning in big circles. This might create enough force to dislodge any vicious code.
Stop the Slashdot effect! Don't read the articles!
And then there is a buffer overflow event, causing data packed collisions, next thing you know I've got your mocha executing in my late.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
No, as others have pointed out it's a flaw in JPEGs and BMP files. PNGs (pretty much the only format used in J2ME in cell phones and PDAs) are safe. Here are the advisories:
http://www.auscert.org.au/render.html?it=7664
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
The biggest concern is that arbitrary applets could be pushed to user's machines. This is mitigated by the fact that the latest JVM's have already been repaired. Thanks to the Java autoupdater, there should not be many desktops at risk.
A secondary concern is servers that accept image uploads. BMPs are usually not accepted anyway, but JPEGs could be a concern. So it is best to upgrade these. Which brings us around to your concern...
For one, it is possible to upgrade these JVMs. It's a bit trickier than a standard install, but it can be done, at least inside the same VM version. (e.g. Java 1.4 apps will usually not suffer from an upgrade to 1.4.1, but a Java 5 upgrade would be disasterous.)
Secondly, I *DO* have a solution. Yell at the vendor! If they're going to stupidly integrate the JVM for no reason other than to make your life difficult (ostensibly to make it easier, yeah right) then they can take the burden of getting you a patch. Don't let the vendor off the hook until they get the problem fixed! That's just good practice, nothing to do with Java.
(Of course, a better practice is to find a vendor who doesn't stupidly integrate JVMs, but I digress.)
BTW, are you talking about Oracle AS or Oracle Database? Oracle AS would need to be patched for situations like this just in case you handle or will handle image uploads. Oracle Database would not be at risk since there is almost no chance of the database being made to parse images in its procedural code. Desktop applications are similarly unaffected unless they download arbitrary images from the internet.
Javascript + Nintendo DSi = DSiCade
That's probably because the bug inside had failed and the battery started corroding causing it to expand and crack the mug.
I clicked on the update tool and it shows an update to Java 1.5. The description says:
/dev/tty,
Update Version: 3832-0
Category: Security
Status: Needed
The Sun JAVA JDK 1.5.0 was upgraded to release 12 to fix
various bugs, including the following security bugs:
CVE-2007-2788 / CVE-2007-3004: Integer overflow in the
embedded ICC profile image parser in Sun Java Development
Kit (JDK), allows remote attackers to execute arbitrary
code or cause a denial of service (JVM crash) via a crafted
JPEG or BMP file.
CVE-2007-2789 / CVE-2007-3005: The BMP image parser in Sun
Java Development Kit (JDK), on Unix/Linux systems, allows
remote attackers to trigger the opening of arbitrary local
files via a crafted BMP file, which causes a denial of
service (system hang) in certain cases such as
and has other unspecified impact.
CVE-2007-0243: Buffer overflow in Sun JDK and Java Runtime
Environment (JRE) allows applets to gain privileges via a
GIF image with a block with a 0 width field, which triggers
memory corruption.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
I just got done installing Java in 3 computer labs, and took the extra step of turning off that damn annoying autoupdate feature in the Java Control Panel on every machine. Crap, there goes my weekend...
I am not left-handed, either!
Am I the only one who originally read this as: Dangerous Lava Flow Threatens 'Virtually Everything'?
"Evil will always triumph over good, because good is dumb." - Dark Helmet (Spaceballs)
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?
So if your JVM includes a JIT, it is not so farfetched for it to be "pure" Java. (The privileged bytecodes are an extension to the Java standard.) Such a design eliminates whole classes of common bugs. Unfortunately, there are infinitely many additional classes of bugs to take their place. One reason why production JVMs are still coded in C is that the code generation of mature C compilers is so much better than a first generation JIT.
If you have multiple Java versions on your computer and/or you do not know which version is used by your browser, try this page:
http://www.javatester.org/version.html
According to AusCERT, http://www.auscert.org.au/render.html?it=7664
you are vulnerable, if your JRE is:
- Sun Java Runtime Environment (JRE) 6
- Sun Java Runtime Environment (JRE) 5.0 Update 10 and prior
- Sun Java Runtime Environment (JRE) 1.4.2_14 and prior
- Sun Java Runtime Environment (JRE) 1.3.1_20 and prior
You know it is. Java is Write Once, Run Anywhere, remember?
Really, could an article be less informative than this one?
This hole might have been a bit easier for Sun to patch if they hadn't made the automatic updater, jusched.exe such an unstable and annoying piece of junk. Or if they made updates work at all. My JRE is still beta 2 and has never seen an update since.
Screw it. I run Windows anyway, it's not like my system isn't already full of holes. What's one more?
Done with slashdot, done with nerds, getting a life.
You have to have native code implementation of some methods, at some point.
:)
I have to admit that I have been very impressed by the overall security of Java. The design is not inherently safe, so the implementation has to be flawless, and I was extremely skeptical of this approach... but Sun has done an excellent job of implementing the Java security model in Java itself with untrusted code running in the same fully capable virtual machine as trusted code.
This means that for untrusted code, implementing as much as possible in Java is the most secure way to go. And avoiding native OS- or application-specific extensions (like, for a recent example, animated cursors in Firefox) keeps Java from being a carrier for indirect attacks.
There are, however, some caveats:
First, for trusted code (for example, normal applications) avoiding native libraries has a potentially huge performance cost. I'm not talking so much about the overhead of Java itself, but portable OS- and application-independent code can't take advantage things like a native graphics API that's directly mapped to GPU operations. I'm sure you can call OpenGL from Java, but I would hope that you can't do it from a Java applet - so applications should perhaps not be held to such a strict regimen.
Second, one of the problems with Java as a "run anywhere" language for applications is that so much of Java is implemented in Java, emulating a Windows style user interface (I don't have a problem with Sun choosing Windows here, that's where the market is, but it does make Java less attractive to people wanting to "run anywhere".
Third, solving this problem for Java may be less useful when it comes to security than fixing the native libraries so they're secure whether they're called from Java or some other component for the display of untrusted content (like a browser).
The flip side of this last point is that implementing a good browser purely in Java would seem to be a way to avoid that problem... but the catch-22 there is the first and second problems, plus so much of the web now *depends on* plugins like Flash, media players, and even Java itself.
A buffer overflow in images that only affects desktops and servers supporting image uploads
According to the announcement, it allows applets to elevate their privileges.
Bunch of FUD-spreading fear-mongers. Hrumph.
If applets are vulnerable, that's not FUD, it's serious. Of course, it's only the latest in several such vulnerabilities over the years, which is probably why many people just disable Java.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
Yes, that would be the right thing to do. Unfortunately, Java sucks for writing that kind of code.
Can anyone explain why Sun changes the name of the package with every minor version?
J2SE Runtime Environment 5.0 Update 11
Java(TM) SE Runtime Environment 6 Update 1
Java(TM) 6 Update 2
What will the next update be called? J2SE Runtime Environment 6.0 Update 3?
Installer changes every time, too. It is just inconvenient for those that want to do unattended installs.
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!