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."

Comments

Re:And people called me paranoid

[nimr0d]

Except NoScript blocks Java from any unapproved pages, effectively making it have everything to do with this article ;)

Re:And people called me paranoid

[3p1ph4ny]

you're right, except it has little to do with java ;)

Actually, NoScript has an option to block Java, Flash, and all other plugins. So it does, in fact, have something to do with Java.

Original AusCERT

[didiken]

It looks like AusCERT has published on their page about this:

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- 2007-2788

      CVE-2007-2789 at
      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE- 2007-2789

Re:Original AusCERT

[AKAImBatman]

Oh good grief, is that all it is? A buffer overflow in images that only affects desktops and servers supporting image uploads that are not running the latest version of a given JVM? What happened to the spreading to PDAs and cell phones, the problem for all users worldwide, the end of things and mankind himself!?!

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:Original AusCERT

[AKAImBatman]

Looks to me like the major problem is for embedded devices, where the update isn't easy.

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.

First of all, thanks to the OP for the link to AusCERT. Very, very helpful!

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. :-)

Re:Original AusCERT

[burner]

Native methods are there to allow a Java program to call code that has not been written in Java, providing access to things such as platform specific functionality. It does not necessarily make your program run faster and should generally not be used to improve performance.

Re:Extraordinary claims require extraordinary proo

[AKAImBatman]

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.

This isn't new

[radish]

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.

Re:How...useful. :/

[shawnce]

According to CVE-2007-2788 and CVE-2007-2789 any version of Java before "1.5.0_11-b03" and "1.6.x before 1.6.0_01-b06".

Re:Fixed in JRE 5 Update 12?

[Mr. Sketch]

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

Re:The sky is falling

[dgun]

Google Security Team

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.

First vulnerability:
* JDK and JRE 6
* JDK and JRE 5.0 Update 10 and earlier
* SDK and JRE 1.4.2_14 and earlier
* SDK and JRE 1.3.1_20 and earlier

Second vulnerability:
* JDK and JRE 6
* JDK and JRE 5.0 Update 10 and earlier
* SDK and JRE 1.4.2_14 and earlier
* SDK and JRE 1.3.1_19 and earlier

And a link to the Aussie security alert

Re:You forget...

[wol]

While Lisp might be used for nuclear facilities, it is not because of lack garbage collection or because it is only interpreted. Lisp has garbage collection and while development typically takes place using the interpreter, the production program is typically compiled. I don't know Java, so I can't start a rational flamewar over why Lisp is better. (Irrational flamewars, on the other hand...)

Re:You forget...

[JesseMcDonald]

I'm not certain but I once heard someone say that languages like Lisp are used in nuclear facilities because they are quick, stable and can be analyzed mathematically to be proved 'correct.' The garbage collector causes Java to be none of these. Also, I think that since Lisp is interpreted, you can switch a program with another modified program without losing execution or control. Not too sure on the details of that though.

1. Lisp also makes extensive use of garbage collection, although there are real-time garbage collection algorithms for it.
2. Most variants of Lisp are compiled, not interpreted.
3. Despite being compiled, you can indeed update a Lisp program on-the-fly. This is accomplished through partial recompilation and dynamic linking.

Re:Extraordinary claims require extraordinary proo

[AKAImBatman]

It appears to be referring to the GIF exploit, which was patched a couple of months ago.

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- 2007-2788
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE- 2007-2789

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...

The problem is that most Java enterprise software winds up becoming tightly coupled with a specific JVM. (In Oracle's case, a good half-dozen *different* JVMs!) You can't upgrade the JVM without breaking the enterprise app (trust me, I tried, they really work only with the specific JVM shipped), so you're left with vulnerable JVMs and no way to upgrade them. I don't have a solution to that problem.

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:And how?

[ajs]

Wouldn't you just roll it out the same as with any other patch? Yes you would. Which means, a full release cycle. Most enterprises (a catch-all phrase that usually maps to the largest corporate environments, involving thousands of employees) support a range of in-house and 3rd party applications, utilities and infrastructure tools. QA on a release cycle for desktops can cost hundreds of thousands of dollars in employee time and delayed projects, but to perform the release any more cavalierly can result in even more damage.

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

[CustomDesigned]

IBM produced a working demonstration system called "Jalapeno" that codes the entire JVM in Java. If you're wondering how it bootstraps, it is a JIT. So in operation the JVM either interprets bytecode or translates it to native machine code. The JIT has hooks to let a utility translate the bytecode of the JVM itself and package it as a loadable module. The demonstration system supports i386 only. The most interesting part of the project was creating a minimal number of privileged bytecodes to support things like memory management and IO.

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

[AtomicJake]

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

Naming and installer

[pe1chl]

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.