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:And people called me paranoid (Score:0, Informative)
Re:And people called me paranoid (Score:5, Informative)
FUD? (Score:2, Informative)
Re:And people called me paranoid (Score:4, Informative)
More information (Score:3, Informative)
Original AusCERT (Score:5, Informative)
Quoted from
AL-2007.0071 -- [Win][Linux][Solaris] -- Sun Java Runtime Environment vulnerability allows remote compromise [auscert.org.au]
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
Re:Extraordinary claims require extraordinary proo (Score:5, Informative)
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.
This isn't new (Score:5, Informative)
Re:How...useful. :/ (Score:5, Informative)
Re:Fixed in JRE 5 Update 12? (Score:5, Informative)
* 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 [auscert.org.au]
Re:Original AusCERT (Score:5, Informative)
Bunch of FUD-spreading fear-mongers. Hrumph.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
Re:The sky is falling (Score:5, Informative)
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 [auscert.org.au]
Re:You forget... (Score:3, Informative)
Re:You forget... (Score:5, Informative)
Re:Extraordinary claims require extraordinary proo (Score:5, Informative)
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 [auscert.org.au]
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.
Re:Original AusCERT (Score:5, Informative)
No, it doesn't. First off, I guarantee you that J2ME implementations do NOT use the same parsing library as the desktop JVM. It's far too heavyweight. Add to that fact that the embedded implementations are written by the phone vendor, significantly decreasing the risk.
Secondly, J2ME does not support JPEGs or BMPs. The standard only supports PNGs. If you want to open JPEGs, you have to use a pure-Java decoder. (Which would not be vulnerable.)
Thirdly, Java applet support is extremely limited in Symbian devices; the only devices I'm aware of that support applets. It's basically Java ME + a few extra APIs to bring it up to Java 1.1 standards. It's doubtful that these VMs even contain the APIs that are being exploited here.
Oh dear, where are my manners? I'd also like to thank the poster for finding the relevant AusCERT article. Without it, we'd still be at the FUD level.
And SuSE has a patch and details. (Score:3, Informative)
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.
Re:And how? (Score:4, Informative)
Most folks who've worked in small-to-medium businesses or less critical environments (such as education) simply can't comprehend the hell that is trying to coordinate a release to such a large community.
JVM in Java (Score:4, Informative)
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.
Java version used by your broswer (Score:3, Informative)
http://www.javatester.org/version.html [javatester.org]
According to AusCERT, http://www.auscert.org.au/render.html?it=7664 [auscert.org.au]
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
Re:Original AusCERT (Score:4, Informative)
You can't write the whole thing in Java (Score:3, Informative)
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.
not FUD (Score:3, Informative)
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.
Naming and installer (Score:4, Informative)
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.
Re:You can't write the whole thing in Java (Score:1, Informative)
Java 3D, in applet form no doubt:
Java3D API: http://java.sun.com/products/java-media/3D/forDev
Java3D Applets: http://www.garybeene.com/3d/3d-j3d.htm [garybeene.com]
For Item #2:
Native GUI Widgets in Java:
http://www.eclipse.org/swt/ [eclipse.org]
For Item #3:
Java Web Browser: http://html.xamjwg.org/java-browser.jsp [xamjwg.org]
Re:And people called me paranoid (Score:3, Informative)
http://noscript.net/
NoScript blocks JavaScript, Java and other executable content.
Re:You can't write the whole thing in Java (Score:2, Informative)
JAI is still in use. It is still supported (apart from the com.sun* image codecs it originally had). It is complicated to use. It is very powerful.
matfud
Re:Naming and installer (Score:2, Informative)
Java JRE 1.4.2 accepted the same command-line options throughout all version, and they even kept the naming scheme fairly consistent. Java JRE 1.5.0 and JRE 1.6.0 accept a slightly different set of command-line options but it is consistent throughout those releases - the naming convention was a little less consistent but it's not really a big deal for unattended software deployments. The key to managing Java deployments is to remember that by default, the JRE installer (and JDK too, IIRC) will not remove any previous versions, simply install the new one and (usually) make it the default JVM. I used to do desktop software management (Microsoft shop, SMS 2003). Our install base was a mess when I started, with literally dozens of JRE versions in use. Keeping detail to a minimum (if you're that curious, email me), once we decided on an "approved" JRE, I built a wrapper around that JRE installer that would inventory other JREs installed on the box and remove them all before installing our standard JRE. Once most of our systems had a common JRE, it was simpler to manage the upgrade process. I had our SMS deployments structured so that it would identify "out-of-date" JREs and patch them automatically. Whenever we approved a new version it was about half an hour of work on the back-end (marking that version as "current" and tweaking the advertisements). Once the new version was slurped into the hierarchy, any "out-of-date" JREs would be updated in a week (most in considerably less than that).
FYI, the acceptable switches for JRE 1.5 and JRE 1.6 are (see this page [sun.com]):
{some-jre.exe} [/L]
The only difference for JRE 1.4.2 is that it supported an additional parameter: [NETACAPE=1]. For 1.5 and 1.6, [MOZILLA=1] covers installing the Java plugin for both Mozilla and Netscape browsers.
I've found this worked well for us (we actually used some of the extra fonts): {some-jre.exe}
Alternatively, just extract the