Forgot your password?
typodupeerror
Java Programming Security

Dangerous Java Flaw Threatens 'Virtually Everything' 323

Posted by Zonk
from the let-it-cool-down-first dept.
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."
This discussion has been archived. No new comments can be posted.

Dangerous Java Flaw Threatens 'Virtually Everything'

Comments Filter:
  • by nimr0d (312173) * <colin@smartbo x l l c . c om> on Friday July 13, 2007 @11:04AM (#19848913) Homepage
    When I told them NoScript was a great plugin.
  • How...useful. :/ (Score:5, Insightful)

    by Kintar1900 (901219) on Friday July 13, 2007 @11:05AM (#19848927) Homepage

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

    Okay, so which versions are vulnerable?

    • by radarjd (931774) on Friday July 13, 2007 @11:10AM (#19849015)

      Okay, so which versions are vulnerable?

      The article sadly has little more information than the summary. It doesn't say which VMs, only that "exploit is browser independent, as long as it invokes a vulnerable Java Runtime Environment". In other words, the vulnerable VMs are vulnerable.

      • Original AusCERT (Score:5, Informative)

        by didiken (93521) on Friday July 13, 2007 @11:18AM (#19849151) Homepage
        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 [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- 2007-2788 [mitre.org]

              CVE-2007-2789 at
              http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE- 2007-2789 [mitre.org]
        • Re:Original AusCERT (Score:5, Informative)

          by AKAImBatman (238306) * <akaimbatmanNO@SPAMgmail.com> on Friday July 13, 2007 @11:27AM (#19849265) Homepage Journal
          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.
          • not FUD (Score:3, Informative)

            by nanosquid (1074949)
            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 li
            • Re:not FUD (Score:4, Interesting)

              by AKAImBatman (238306) * <akaimbatmanNO@SPAMgmail.com> on Friday July 13, 2007 @02:19PM (#19851451) Homepage Journal

              If applets are vulnerable, that's not FUD, it's serious.

              Of course it's serious. That doesn't mean that it affects everything from mobile devices to servers! That was just plain FUD on the part of the article. They made it sound like every implementation of Java ever was now vulnerable and there is nothing we can do about it. In reality, it's a serious problem, but far less so than advertised. In fact, nearly all desktops should be updated by now thanks to the Java autoupdater.

              Unfortunately, Java sucks for writing that kind of code.

              Oh, don't start. I've written plenty of image and datafile loading routines in Java. You don't get nice "struct" features* for memory management, but that doesn't materially impact the ability to load and parse the data. The biggest thing to remember is that some formats use endians in something other than network order. (I'm looking at you Ronald Rivest! Do you know how much it would have saved me if MD5 used the same byte order as every other RFC under the sun? Grr...)

              * I did write a proof-of-concept "struct" pre-processor once in an attempt to make a colleague happier. It basically added a new form of class type other than "class" and "interface". When parsed, it would be transformed into a ByteBuffer object with getX()/setX() accessors/mutators that accessed the correct locations of the buffer.
        • Re: (Score:2, Interesting)

          by jimbojw (1010949)
          I thought one of the big selling points of Java (over C++ back in the day) was that it would be immune to buffer overflows due to it's object representation and garbage collection mechanism. Was that just hype?
          • by AKAImBatman (238306) * <akaimbatmanNO@SPAMgmail.com> on Friday July 13, 2007 @12:06PM (#19849803) Homepage Journal
            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.
            • 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 mu
    • And how? (Score:4, Interesting)

      by khasim (1285) <brandioch.conner@gmail.com> on Friday July 13, 2007 @11:14AM (#19849083)
      I'm not seeing ANYTHING there aside from melodramatic hyperbole.

      "It would be an extremely difficult and laborious process for an organization trying to patch Java Runtime across the enterprise," he said.

      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.
      • by cnettel (836611)
        One issue is that several (Java-based) applications tend to roll their own version of the JRE for "convenience". On the other hand, those apps hopefully do not use Java sandboxing to load arbitrary code safely from the net.
      • Re:And how? (Score:4, Informative)

        by ajs (35943) <<moc.sja> <ta> <sja>> on Friday July 13, 2007 @12:49PM (#19850323) Homepage Journal

        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.
        • 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 mediu
    • Re:How...useful. :/ (Score:5, Informative)

      by shawnce (146129) on Friday July 13, 2007 @11:27AM (#19849259) Homepage
      According to CVE-2007-2788 [mitre.org] and CVE-2007-2789 [mitre.org] any version of Java before "1.5.0_11-b03" and "1.6.x before 1.6.0_01-b06".
  • by Anonymous Coward on Friday July 13, 2007 @11:05AM (#19848945)
    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.
    • by greenreaper (205818) on Friday July 13, 2007 @11:09AM (#19848999) Homepage Journal
      What about the people using it to run nuclear reactors?
      • by Azar (56604) on Friday July 13, 2007 @11:13AM (#19849055) Homepage
        Well, as long as they aren't using the nuclear reactor to browse warez sites, I think we will be fine.
      • Re:You forget... (Score:5, Interesting)

        by Anonymous Coward on Friday July 13, 2007 @11:13AM (#19849061)
        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 [java.com]:

        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.
        • I know. (Score:4, Insightful)

          by greenreaper (205818) on Friday July 13, 2007 @11:21AM (#19849189) Homepage Journal
          That's what makes it a joke, for all those who've actually read the license agreement. :-)
        • Re:You forget... (Score:5, Insightful)

          by Ambitwistor (1041236) on Friday July 13, 2007 @11:36AM (#19849395)
          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?
          • Or perhaps Lisp's garbage collector is quick, stable, with mathematically provable behavior, and Java's is not?

            Still, I was under the impression that engineering software with critical real time constraints (which I would imagine nuclear plants to have) tends to avoid the unpredictability of GCs. Though I am sure there has been work on realtime GCs with guaranteed behavior, somewhere, ...
        • Re: (Score:3, Informative)

          by wol (10606)
          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...)
          • by computational super (740265) on Friday July 13, 2007 @12:21PM (#19850005)
            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.

            • Re: (Score:3, Funny)

              by jason8 (917879)

              Have you heard of the major Lisp nuclear controller hack of a few years ago? Apparently, hackers somehow managed to get into a nuclear reactor site and make a copy of the top-secret Lisp program used to control the reactor. I can't post the entire program for security reasons, but I will post the last page:

              (Imagine a page full of right-parens)

        • Re:You forget... (Score:5, Informative)

          by JesseMcDonald (536341) on Friday July 13, 2007 @11:43AM (#19849493) Homepage

          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:You forget... (Score:5, Insightful)

          by timster (32400) on Friday July 13, 2007 @11:45AM (#19849529)
          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.
          • by kabdib (81955) on Friday July 13, 2007 @02:35PM (#19851629) Homepage
            Low tech is better.

            Those relays are powered by *steam*, and serve only to control arms in the corridor outside the control room which raise and lower colored flags. Mesopotamian runner-slaves note the configuration of the flags and carry messages to more slaves stationed near the reactor core who in turn are responsible for raising and lowering the control rods, who man the coolant pumps, and in a pinch, who sacrifice goats to the altar of O'krap, the God of Reactor Meltdowns.

            Speaking tubes were tried once ("Ahoy! More coolant on the starboard pile, and hoist up control rod three!") but finding reactor operators who knew Urdu was too difficult.

            The Nuclear Safety Council is considering a move to systems based on "electrics," but the committee responsible for this investigation has been unable to locate the inventors B. Franklin and T. Edison.
        • by glwtta (532858)
          The garbage collector has an impact on the correctness of a program now? Is there any limit to the evils of the Java garbage collector?
        • Re: (Score:3, Insightful)

          by nasch (598556)

          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.

          I don't know enough about mathematical proofs of software to comment on that, but I don't believe the GC causes Java to be either unstable or slow. What it does is cause it to be unpredictable - execution could pause at any time for GC to take place.

    • 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.
    • I'm pretty sure my shoes and coffee mug are going to make it through this ordeal.

      You coffee mug is especially vulnerable to java.

      I can also see where this vulnerability might extend to your shoes, especially if you are standing, holding a coffee mug with java installed, and there are other java users moving around you.
    • > 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.

      I don't know...I'm still pretty worried. Last night, I set some stuff out on the curb.

      This morning, it got garbage collected.
  • FUD? (Score:2, Informative)

    by DrJonesAC2 (652108)
    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.
    • by hkgroove (791170)
      Did Google recently hire a bunch of former White House spindoctors?
    • "It would be an extremely difficult and laborious process for an organization trying to patch Java Runtime across the enterprise," he said.

      It's like Windows!

      Non free FUD wars are so entertaining. The war on Java will get twice as hot now that Sun is freeing it. ZDNet won't know if they should call it Dangerous or Cancer.

  • 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. :-/
    • 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.
      • by jZnat (793348) *
        Ubuntu has Sun Java packages available (not installed by default), so you can get automatic updates with that. I don't know if Debian still has those packages in non-free, but when Sun JDK/JRE 7 come out (GPLv3), they should be included in main. Gentoo has an ebuild for it already, so just hope that the ebuild gets updated as usual. I don't know about the Red Hat family of distros, but they're probably covered just as well.
    • It's probably Security Vulnerabilities in the Java Runtime Environment Image Parsing Code May Allow a Untrusted Applet to Elevate Privileges [sun.com], which sounds like a flaw in native code that loads images.

      Note that this kind of vulnerability can happen in anything using unsafe code. It is not an indictment against Java's security model, it's just a bug in the native code libraries used to make the implementation faster. Also .NET uses more native code than Java so one would expect similar kinds of bugs to affe
  • Does anyone have a link to the actual "Google Security Team" report on the issue, or an announcement from them on having discovered the issue?

    The article rages about the whole universe being at risk (ignoring the fact that Java has had an auto-update mechanism for quite a while) but doesn't say which JVMs are at risk.

    I can't actually find ANYTHING else beyond the chicken licken article here on what the issue is.
    • by dgun (1056422) on Friday July 13, 2007 @11:28AM (#19849273) Homepage

      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 [auscert.org.au]

  • by Aefix (968923) on Friday July 13, 2007 @11:09AM (#19848997)
    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?
  • The browser plug-in is based on gcc.
  • ...Pure Hacking will provide a complete explanation of the vulnerability.

    For an additional undetermined sum, Pure Hacking will offer an ambiguous and nefarious fix for the vulnerability.

  • by Anonymous Coward on Friday July 13, 2007 @11:14AM (#19849087)
    I'm pretty sure this is it:

    http://groups.google.com/group/ph4nt0m/msg/05b1131 63fb0cc55 [google.com]
    • by Cheesey (70139)
      I'm pretty sure this is it:

      That's a different flaw in Java Web Start.

      Right now, in this topic, I can see three possible links to Java flaws that "could be it". It's great that contributors to this topic have been able to dig up these links, but really, the original article should have included some details about the exploit so that we would all be in no doubt about what it actually involves. As it is, both the submission and the ZDnet article include no details at all. Nothing. What's the point of that? It'
  • One Huge Problem (Score:3, Insightful)

    by Anonymous Coward on Friday July 13, 2007 @11:15AM (#19849091)
    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)
  • More information (Score:3, Informative)

    by greenreaper (205818) on Friday July 13, 2007 @11:15AM (#19849099) Homepage Journal
    This CNET article [com.com] has more information. There is a vulnerability report [sun.com] 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.
  • by iBod (534920) on Friday July 13, 2007 @11:16AM (#19849111)
    >>Due to the ubiquitousness of Java, this could prove a serious security problem.

    Ah! That would be 'ubiquity' then?

    FFS editors!
    • by LMacG (118321)
      Merriam-Webster seems to be of two [merriam-webster.com] minds [merriam-webster.com] on this subject.
      • by iBod (534920)
        Merriam-Webster is simply following the trend of dumbing-down the English language.

        Dumb people think their words carry more weight if they add a few syllables.
  • Having read what little there was in the article, can ANYone substantiate or explain the risks here?

    Pure Hacking's Gatford said the problem is compounded by the slim chance of an enterprise patching Java Runtime vulnerabilities.

    "It would be an extremely difficult and laborious process for an organization trying to patch Java Runtime across the enterprise," he said.

    I agree, but, since when has patching been easier on something else?

    Australia's Computer Emergency Response Team (AusCERT) analyst, Robert Lowe,

    • Pure Hacking's Gatford said the problem is compounded by the slim chance of an enterprise patching Java Runtime vulnerabilities.

      "It would be an extremely difficult and laborious process for an organization trying to patch Java Runtime across the enterprise," he said.

      I agree, but, since when has patching been easier on something else?

      I think it's easier among corporations, where there's likely to be an IT group and an inventory of hardware. If they're deploying java, then they're more likel

      • by davecb (6526) *

        Any serious enterprise will have a patch policy and process, if only a spinal reflex to "patchadd /tmp/jre-6ui-something" from their sysadmin (;-))

        Mere humans can click the big "Free Java Download" button at java.com.

        Some, but not all, telephone users will get a free call to the update center.

        --dave

  • Friday the 13th is the new April Fool's Day!
  • by MarkWatson (189759) on Friday July 13, 2007 @11:19AM (#19849165) Homepage
    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.
    • by fm6 (162816)
      The articles a ZDNET newflash, probably prepared in a hurry. When journalists are doing a breaking story, they don't have time to get all the details. Presumably we'll see more in-depth stuff later in the day.

      I fault the editor (let's see who is it? uh huh, Zonk, what a suprise) for not taking the time to dig up the actual security bulletin, or at least waiting for a submission that contains a link to an article that actually describes the exploit.
  • by pw700z (679598) on Friday July 13, 2007 @11:20AM (#19849181)
    ...at least we can be assured whatever disaster happens, it will happen slowly. Just kidding!
  • If this is about the buffer overflow in JNLP [eeye.com] ("Sun Java WebStart JNLP Stack Buffer Overflow Vulnerability"), then the fix has already been released with JRE 5 Update 12 and the latest JRE 6 update.
  • The alert is accessible at http://www.auscert.org.au/render.html?it=7664 [auscert.org.au].

    Not sure what all the noise is about. The security "experts" from penetration testing firm Pure Hacking are twats for blowing this all out of proportion.

  • This isn't new (Score:5, Informative)

    by radish (98371) on Friday July 13, 2007 @11:23AM (#19849225) Homepage
    This issue (I'll provide a link [auscert.org.au] 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.
  • This is a link to Google's Online Security Blog [blogspot.com]. Nothing there about the sky falling if you're using Java. Granted, there's some stuff there on virtual machines, but nothing specifically related to JVMs.

    I find this an extremely hard story to swallow, especially given the lack of details in the article. I'm surprised this story even passed Slashdot's screening process.

    • by josepha48 (13953)
      I find it hard to swallow too. Java has an update program, that by default will check for new versions of the JRE. Also I didn't see them say what kind of security risk this is. Will someone take over the computer or potentially steal data, does it affect all OS?

      This is very vague. if I came to my boss with this kind of info, he tell me to get the f*** out of his office. WTF!

  • This proves two things:

    a) a virtual environment is as secure as its host.

    b) it's time to stop using C.

    (the above is valid if the flaw is in JNLP and/or ICC handling code, as some posters said).

  • ....theres a reason why the problem with the JVM is not described. If it was, every cracker would be able to write an exploit pretty damn pronto!
  • Well, I can see why you can't say "Do this, this and this and behold, a buffer overflow. Now here and here some code and presto, code injection".

    But this article reads kinda like a mix of a homeland security threat warning and a political speech. There's some kinda-sorta threat, and we deem it critical, and all hell breaks loose if someone steps into it.

    What kinda "information" is that? The link to the actual information has been posted before (yeah, yeah, mod me redundant, my karma will soak it), but could
  • ``even though the browser may be fully patched, some people neglect to also patch programs invoked by browsers to render specific types of content''

    No problem. When you do apt-get upgrade to install the latest, patched version of your browser, it also updates all your other software. Wait! You _are_ using an operating system with a proper package manager, are you?!

    Note that I'm saying this not to flame anyone's operating system or to assert apt-get's superiority, but simply to drive home a point I've made b
  • by AaronW (33736) on Friday July 13, 2007 @12:30PM (#19850113) Homepage
    I clicked on the update tool and it shows an update to Java 1.5. The description says:

    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 /dev/tty,
    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.
  • by bensafrickingenius (828123) on Friday July 13, 2007 @12:41PM (#19850219)
    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...
  • Lava Flow (Score:4, Funny)

    by Kinthelt (96845) on Friday July 13, 2007 @12:47PM (#19850281) Homepage
    Am I the only one who originally read this as: Dangerous Lava Flow Threatens 'Virtually Everything'?
  • by AtomicJake (795218) on Friday July 13, 2007 @01:12PM (#19850605)
    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 [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
  • by stuntpope (19736) on Friday July 13, 2007 @01:26PM (#19850789)
    Really, could an article be less informative than this one?
  • by nuzak (959558) on Friday July 13, 2007 @01:26PM (#19850795) Journal
    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?

  • Naming and installer (Score:4, Informative)

    by pe1chl (90186) on Friday July 13, 2007 @02:12PM (#19851361)
    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.

Air is water with holes in it.

Working...