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

19 of 323 comments (clear)

  1. How...useful. :/ by Kintar1900 · · Score: 5, Insightful

    Also, this exploit is browser independent, as long as it invokes a vulnerable Java Runtime Environment

    Okay, so which versions are vulnerable?

    1. Re:How...useful. :/ by shawnce · · Score: 5, Informative

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

  2. 'Virtually Everything' or 'Everything Virtual'? by Anonymous Coward · · Score: 5, Funny
    I think that

    Dangerous Java Flaw Threatens 'Virtually Everything' Should read

    Dangerous Java Flaw Threatens 'Everything Virtual' I mean, Java is just a freaking virtual machine, not the underpinnings of all laws of physics. I'm pretty sure my shoes and coffee mug are going to make it through this ordeal.
    1. Re:'Virtually Everything' or 'Everything Virtual'? by Vulva+R.+Thompson,+P · · Score: 5, Funny

      I'm pretty sure my shoes and coffee mug are going to make it through this ordeal.

      Speak for yourself, some of us use Java in our coffee mugs. The upcoming patch is supposed to correct a number of leaks.

  3. Re:And people called me paranoid by nimr0d · · Score: 5, Informative

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

  4. Extraordinary claims require extraordinary proof by AKAImBatman · · Score: 5, Insightful

    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. "Java runs on everything: cell phones, PDAs, and PCs. This is the problem when you have a vulnerability in something so modular--it affects so many different devices.," said Gatford.

    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. :-/
  5. TFA is extremely vague by Aefix · · Score: 5, Insightful

    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?

  6. Re:You forget... by Azar · · Score: 5, Funny

    Well, as long as they aren't using the nuclear reactor to browse warez sites, I think we will be fine.

  7. Re:You forget... by Anonymous Coward · · Score: 5, Interesting
    I'm pretty sure that Java's license explicitly states that it should not be used to run nuclear reactors. You might think I'm joking but from here:

    You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. 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.
  8. Original AusCERT by didiken · · Score: 5, Informative

    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

    1. Re:Original AusCERT by AKAImBatman · · Score: 5, Informative

      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.

    2. Re:Original AusCERT by AKAImBatman · · Score: 5, Informative

      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. :-)
  9. Well, since this impacts Java... by pw700z · · Score: 5, Funny

    ...at least we can be assured whatever disaster happens, it will happen slowly. Just kidding!

  10. Re:Fixed in JRE 5 Update 12? by Mr.+Sketch · · Score: 5, Informative

    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

  11. Re:The sky is falling by dgun · · Score: 5, Informative

    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

    --
    FAQs are evil.
  12. To quote Harry Dresden... by Anonymous Coward · · Score: 5, Funny

    Just because you are paranoid doesn't mean there isn't an invisible demon out to eat your face.

  13. Re:You forget... by JesseMcDonald · · Score: 5, Informative

    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.
    --
    "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  14. Re:You forget... by timster · · Score: 5, Insightful

    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.
  15. Re:You forget... by computational+super · · Score: 5, Funny
    I don't know Java, so I can't start a rational flamewar over why Lisp is better.

    Lisp is preferred in high-security installations (such as nuclear generators) because it's an extra layer of security. Even if a hacker can breach the outer defences, no actual human being can comprehend a Lisp program, so there's no danger of the hacker doing any damage.

    --
    Proud neuron in the Slashdot hivemind since 2002.