Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Dangerous Java Flaw Threatens 'Virtually Everything'

Zonk posted more than 7 years ago | from the let-it-cool-down-first dept.

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

cancel ×

323 comments

Sorry! There are no comments related to the filter you selected.

And people called me paranoid (4, Insightful)

nimr0d (312173) | more than 7 years ago | (#19848913)

When I told them NoScript was a great plugin.

Re:And people called me paranoid (0, Informative)

Anonymous Coward | more than 7 years ago | (#19848951)

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

Re:And people called me paranoid (5, Informative)

nimr0d (312173) | more than 7 years ago | (#19848967)

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

Re:And people called me paranoid (4, Informative)

3p1ph4ny (835701) | more than 7 years ago | (#19848985)

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.

Re:And people called me paranoid (-1, Redundant)

casings (257363) | more than 7 years ago | (#19849085)

javascript != java

Re:And people called me paranoid (1)

nimr0d (312173) | more than 7 years ago | (#19849127)

Good thing I'm talking about java, and NOT javascript.

Re:And people called me paranoid (-1, Offtopic)

casings (257363) | more than 7 years ago | (#19849173)

don't blame him, your initial description was rather vague, much like the article...

Re:And people called me paranoid (-1, Offtopic)

casings (257363) | more than 7 years ago | (#19849203)

apologies, him should read me...

need coffee...

To quote Harry Dresden... (5, Funny)

Anonymous Coward | more than 7 years ago | (#19849299)

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

How...useful. :/ (5, Insightful)

Kintar1900 (901219) | more than 7 years ago | (#19848927)

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

Okay, so which versions are vulnerable?

Re:How...useful. :/ (3, Funny)

radarjd (931774) | more than 7 years ago | (#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 (5, Informative)

didiken (93521) | more than 7 years ago | (#19849151)

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 (5, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19849265)

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 (1)

Kintar1900 (901219) | more than 7 years ago | (#19849365)

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

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?

Looks to me like the major problem is for embedded devices, where the update isn't easy. All you'd have to do is create a web page with an applet that displays images, then custom-craft a JPG file to exploit the weakness. Remember, applets run on the client's VM, so the mobile/embedded device would be the one executing the attacking code, not the web server. Viola, anyone you can entice into viewing your web page has just been breached.

Granted, not /quite/ the gloom and doom of the article, but still a major, valid security hole.

Re:Original AusCERT (5, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19849731)

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 (1)

tritonman (998572) | more than 7 years ago | (#19849627)

Does this mean that if I am using the Microsoft VM then I am safe??

Re:Original AusCERT (2, Interesting)

jimbojw (1010949) | more than 7 years ago | (#19849677)

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?

And how? (3, Interesting)

khasim (1285) | more than 7 years ago | (#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.

Re:And how? (1)

cnettel (836611) | more than 7 years ago | (#19849281)

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

shawnce (146129) | more than 7 years ago | (#19849259)

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

'Virtually Everything' or 'Everything Virtual'? (5, Funny)

Anonymous Coward | more than 7 years ago | (#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.

You forget... (4, Funny)

greenreaper (205818) | more than 7 years ago | (#19848999)

What about the people using it to run nuclear reactors?

Re:You forget... (5, Funny)

Azar (56604) | more than 7 years ago | (#19849055)

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

Re:You forget... (5, Interesting)

Anonymous Coward | more than 7 years ago | (#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. (3, Insightful)

greenreaper (205818) | more than 7 years ago | (#19849189)

That's what makes it a joke, for all those who've actually read the license agreement. :-)

Re:You forget... (4, Insightful)

Ambitwistor (1041236) | more than 7 years ago | (#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?

Re:You forget... (1)

Ambitwistor (1041236) | more than 7 years ago | (#19849431)

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

MenTaLguY (5483) | more than 7 years ago | (#19849541)

There is no single standard behavior for Lisp garbage collection, nor even really is "Lisp" a single language. It's a wild forest of various implementations and dialects, some of them confederated under the Common Lisp specification.

Re:You forget... (3, Informative)

wol (10606) | more than 7 years ago | (#19849469)

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... (5, Informative)

JesseMcDonald (536341) | more than 7 years ago | (#19849493)

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... (5, Insightful)

timster (32400) | more than 7 years ago | (#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.

Re:'Virtually Everything' or 'Everything Virtual'? (0)

Anonymous Coward | more than 7 years ago | (#19849045)

Please note:

When I read this, I was so shocked that I kicked my shoes against the table. My coffee mug fell off the table and my shoes are now cracked.

You are wrong, this is a vile thread indeed.

Re:'Virtually Everything' or 'Everything Virtual'? (5, Funny)

Vulva R. Thompson, P (1060828) | more than 7 years ago | (#19849115)

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.

Are you sure? (1)

raehl (609729) | more than 7 years ago | (#19849253)

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.

Re:Are you sure? (2, Funny)

networkBoy (774728) | more than 7 years ago | (#19849481)

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.

Re:'Virtually Everything' or 'Everything Virtual'? (0)

Anonymous Coward | more than 7 years ago | (#19849389)

The first time I read it I thought it said "Dangerous Lava Flow threatens virtually Everyone"

Re:'Virtually Everything' or 'Everything Virtual'? (1)

Mr. Bad Example (31092) | more than 7 years ago | (#19849425)

> 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? (3, Informative)

DrJonesAC2 (652108) | more than 7 years ago | (#19848975)

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.

Re:FUD? (1)

hkgroove (791170) | more than 7 years ago | (#19849019)

Did Google recently hire a bunch of former White House spindoctors?

OMG, OMG, Did you Read the Article? (1)

twitter (104583) | more than 7 years ago | (#19849207)

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

OMG, OMG, you sound like a sorority girl! (0)

Anonymous Coward | more than 7 years ago | (#19849449)

Have you got any proof that ZDNet shills for Microsoft, or are you just making up prize bullcrap as usual?

Re:FUD? (0)

Anonymous Coward | more than 7 years ago | (#19849213)

Yep, and MS releases a patch that causes some screwy behaviour solved by a reboot it gets tagged:

microsoft, programming, security, theballmerpatch, scary

Java flaw?

java, security

I don't know why I bother anymore.

Extraordinary claims require extraordinary proof (5, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#19848983)

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

Re:Extraordinary claims require extraordinary proo (4, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19849153)

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.

Re:Extraordinary claims require extraordinary proo (1)

Trailrunner7 (1100399) | more than 7 years ago | (#19849175)

First, this is more than a month old and has been patched. And B, ubiquitousness isn't a word. Not even in Australia.

Re:Extraordinary claims require extraordinary proo (0)

Anonymous Coward | more than 7 years ago | (#19849179)

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

And the article is correct, attempting to patch vulnerable JVMs turns out to be practically impossible. 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. The one plus side to Java vulnerabilities is that Java runs on many platforms, so it may be slightly harder to exploit a flaw. But it's essentially impossible to patch a flaw should it become discovered without waiting for each vendor to update their enterprise software to support the new JVM.

In the end, the network security guys threatened to pull the machine off the network unless we could replace the faulty JVMs, so we just gave up on using Java. It was just an evaluation, and there are other solutions out there that don't cause the security problems Java does.

Re:Extraordinary claims require extraordinary proo (4, Informative)

AKAImBatman (238306) | more than 7 years ago | (#19849509)

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

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:Extraordinary claims require extraordinary proo (0)

Anonymous Coward | more than 7 years ago | (#19849641)

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.

Doesn't matter. The computer security people install software on all network-connected PCs that scans for vulnerable software. If it finds a vulnerable JVM, they'll make you patch it or move the machine offline. Even if it doesn't make sense.



Like the article said, trying to upgrade Java in the enterprise is nearly impossible. The place I work uses the solution of forcing the issue by scanning the entire filesystem for vulnerable applications, which includes JVMs.

Re:Extraordinary claims require extraordinary proo (1)

0xABADC0DA (867955) | more than 7 years ago | (#19849239)

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

This kind of problem will not exist once all of our libraries and operating systems have been written in safe languages such as Java.

Re:Extraordinary claims require extraordinary proo (1)

moco (222985) | more than 7 years ago | (#19849269)

Well said!

How are my JSP/Servlet servers affected by this? Even if i was running the most unsecure version of java, I choose what code runs on them. People don't use the server's vm to execute random applets from the internet.

Re:Extraordinary claims require extraordinary proo (1)

Josef Meixner (1020161) | more than 7 years ago | (#19849455)

Even if i was running the most unsecure version of java, I choose what code runs on them.

According to the AusCERT report the bug is in the image parsing code. So if your Servlet somehow accesses images being uploaded or residing on a third party server, it is vulnerable.

In that case, the attacker might be able to run any executable on your server.

Anyone have details? (1)

StarEmperor (209983) | more than 7 years ago | (#19848991)

Does anyone have any details on this beyond "virtually everything is threatened?"

Re:Anyone have details? (4, Funny)

Geek of Tech (678002) | more than 7 years ago | (#19849433)

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.

The sky is falling (1)

MosesJones (55544) | more than 7 years ago | (#19848993)

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.

Re:The sky is falling (5, Informative)

dgun (1056422) | more than 7 years ago | (#19849273)

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]

TFA is extremely vague (5, Insightful)

Aefix (968923) | more than 7 years ago | (#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?

use Fedora 7 (1)

r00t (33219) | more than 7 years ago | (#19849001)

The browser plug-in is based on gcc.

This is one time you should RTFA (0)

Anonymous Coward | more than 7 years ago | (#19849023)

There is enough meat in this article to make a whole stack of boca burgers.

Simplest solution to this and all future bugs (-1, Redundant)

InvisblePinkUnicorn (1126837) | more than 7 years ago | (#19849039)

Disable javascript.

In IE, go to Tools > Internet Options. On the Security tab, click Custom Level, and set all the Scripting options to Disable (or Prompt).

In Firefox, go to Tools > Options. On the Content tab, uncheck the Java/Javascript options.

Re:Simplest solution to this and all future bugs (2, Insightful)

ukatoton (999756) | more than 7 years ago | (#19849093)

Java != Javascript

If you're paranoid, at least disable the right thing.

Re:Simplest solution to this and all future bugs (1)

The MAZZTer (911996) | more than 7 years ago | (#19849113)

About a page up, someone mentions that the NoScript Firefox extension can block Java applets, which is probably a more convenient choice rather than disabling Java all together.

Another point for Firefox! Against IE at least.

Re:Simplest solution to this and all future bugs (0)

Anonymous Coward | more than 7 years ago | (#19849375)

Just disable Java outright in Firefox by going to the Content section of Preferences. Then you don't have to wait 10 seconds if you happen to hit a page that uses Java.

Re:Simplest solution to this and all future bugs (0)

Anonymous Coward | more than 7 years ago | (#19849117)

I was about to reply then realised I'd been trolled!

Re:Simplest solution to this and all future bugs (2, Insightful)

Nadir (805) | more than 7 years ago | (#19849145)

Java != Javascript

How many times have we seen this comment...

Re:Simplest solution to this and all future bugs (0)

Anonymous Coward | more than 7 years ago | (#19849323)

I think you can leave Javascript enabled, just turn off Java. I think the only time I've ever had Java enabled anyways was to play Yahoo games.

Having Java enabled has a usefullness/security-vulnerability ratio almost as bad as ActiveX.

Re:Simplest solution to this and all future bugs (1)

ChrisGilliard (913445) | more than 7 years ago | (#19849545)

Uhh yeah, and while you're at it, disable flash, java, and just use a text browser like lynx. Who needs all this web 2.0 content anyways. I mean does anyone actually enjoy watching youtube, using Google maps, using zillow.com or chatting through a web interface or going to sites that use javascript like slashdot?

For the Very Low Price of .... (2, Funny)

slas6654 (996022) | more than 7 years ago | (#19849043)

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

here is the security flaw (3, Interesting)

Anonymous Coward | more than 7 years ago | (#19849087)

I'm pretty sure this is it:

http://groups.google.com/group/ph4nt0m/msg/05b1131 63fb0cc55 [google.com]

Re:here is the security flaw (1)

Cheesey (70139) | more than 7 years ago | (#19849393)

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's about as effective as raising the "terror alert" to "critical".

Seems that the flaw is most likely this one: http://www.auscert.org.au/render.html?it=7664 [auscert.org.au] - it's an image decoding bug.

One Huge Problem (3, Insightful)

Anonymous Coward | more than 7 years ago | (#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 (2, Informative)

greenreaper (205818) | more than 7 years ago | (#19849099)

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.

Doh, ignore the above :-) (2, Funny)

greenreaper (205818) | more than 7 years ago | (#19849155)

That was yet another serious Java bug. Unless they've decided to review a story from January, which I guess is always possible.

That article (0, Troll)

Rik Sweeney (471717) | more than 7 years ago | (#19849101)

was nearly as underwhelming as Microsoft's E3 showing

Pow, Right in the kisser!

Ubiquitousness? (3, Funny)

iBod (534920) | more than 7 years ago | (#19849111)

>>Due to the ubiquitousness of Java, this could prove a serious security problem.

Ah! That would be 'ubiquity' then?

FFS editors!

Re:Ubiquitousness? (1)

LMacG (118321) | more than 7 years ago | (#19849311)

Merriam-Webster seems to be of two [merriam-webster.com] minds [merriam-webster.com] on this subject.

Re:Ubiquitousness? (0)

Anonymous Coward | more than 7 years ago | (#19849575)

Ah! That would be 'ubiquity' then?

I think you mean 'ubiqitousnessfulitude'.

Excellent example of why Open Source wins... (-1, Troll)

Cragen (697038) | more than 7 years ago | (#19849135)

Someone makes a claim. They gotta back it up with defendable examples. Can't do that too well with proprietary *cough* M$ *cough*. Looking forward to the "defense" of the claim. That's why they call 'em "claims". Happy Friday!

Re:Excellent example of why Open Source wins... (0)

Anonymous Coward | more than 7 years ago | (#19849301)

wtf does your comment even mean?? knowing the mods around here though, you'd probably get modded insightful or something equally stupid.

Useless Article (1)

TALlama (462873) | more than 7 years ago | (#19849137)

Could they manage to say less in this article? There's no reference to what the flaw is, how bad it is; anything. The mention that Google Engineers found it, and then some analysts talk about how it could be a problem for all browsers that have a JVM, which sounds analysty and most likely wrong.

I did a search on Google News [google.com] and came up with nothing BUT this article.

Anyone have anything more concrete?

The Fearmongering... (1)

decipher_saint (72686) | more than 7 years ago | (#19849143)

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, warned that anyone using the Java Runtime Environment or Java Development Kit is at risk.

Is... is that a threat? A threat from a bogeyman waving a "The End of the Java World is Nigh" sign?

Re:The Fearmongering... (1)

lena_10326 (1100441) | more than 7 years ago | (#19849255)

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 likely to be setup to maintain updates. They already have a maintenance infrastructure.

It's the cell and home user I would be concerned about. They don't know what they have or why it's important to update.

SOD - Superstition Obfuscation Demagoguery (2, Funny)

kippa (453370) | more than 7 years ago | (#19849163)

Friday the 13th is the new April Fool's Day!

Sounds like a warning from 'Homeland Security' (2, Insightful)

MarkWatson (189759) | more than 7 years ago | (#19849165)

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.

Well, since this impacts Java... (5, Funny)

pw700z (679598) | more than 7 years ago | (#19849181)

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

Re:Well, since this impacts Java... (1)

_Sprocket_ (42527) | more than 7 years ago | (#19849373)

And on the plus side, the exploit is probably version-specific. ;)

Fixed in JRE 5 Update 12? (1)

uss_valiant (760602) | more than 7 years ago | (#19849201)

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.

Re:Fixed in JRE 5 Update 12? (5, Informative)

Mr. Sketch (111112) | more than 7 years ago | (#19849261)

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

AusCERT alert. (1)

merdaccia (695940) | more than 7 years ago | (#19849223)

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 (4, Informative)

radish (98371) | more than 7 years ago | (#19849225)

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.

J9 (1)

QBasicer (781745) | more than 7 years ago | (#19849233)

I wonder if this affects IBM's J9 in any way?

In Firefox (1)

zentrii (1127677) | more than 7 years ago | (#19849297)

In Firefox will it help to at least uncheck Enable Java in /Options/Content?

Nothing on Google's Security Blog (1)

gubachwa (716303) | more than 7 years ago | (#19849313)

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.

Re:Nothing on Google's Security Blog (1)

josepha48 (13953) | more than 7 years ago | (#19849513)

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!

Open Sores (0)

Anonymous Coward | more than 7 years ago | (#19849335)

You see? Had this been Open Source intsead of Open Sores, this would not have happened.

This shows the usefulness and versatility of Java (1)

Waffle Iron (339739) | more than 7 years ago | (#19849515)

Write once, pwn anywhere!

Wow, a scary article. (1)

WWWWolf (2428) | more than 7 years ago | (#19849597)

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.

Oh wow, that sounds really scary. I really wouldn't want to be in the Enterprisey world. I mean, they don't seem to have apt-get there. Or any of those mass-update tools in Windowsland. And they disabled that Java Windows autoupdate thingy because, well, who needs that?...

FUDdy, huh?

It's a C/C++ flaw in the Java environment. (1)

master_p (608214) | more than 7 years ago | (#19849617)

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

WHAT IS THE vulnerability? (1)

recharged95 (782975) | more than 7 years ago | (#19849621)

Google team reports an AusCERT find? AND no details? A simple sentence saying what the error is? Is it patched?

Sounds like someone saying "Mission accomplished" w/o showing any proof--sounds like FUD.

Perhaps..... (1)

BigBadBus (653823) | more than 7 years ago | (#19849623)

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

Beware of giving out specifics! (1)

Opportunist (166417) | more than 7 years ago | (#19849639)

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 we PLEASE get submissions that actually contain links to some info? I mean, I'd already be happy with some slander and propaganda, but I'm feverishly against a waste of bandwidth like the linked article.

Think of us commenters! How do you think we should comment if there's nothing to comment on?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>