Dangerous Java Flaw Threatens 'Virtually Everything' 323
Marc Nathoni writes with a ZDet article about a critically dangerous hole in the Java Runtime Environment. Due to the ubiquitousness of Java, this could prove a serious security problem. "Australia's Computer Emergency Response Team (AusCERT) analyst, Robert Lowe, warned that anyone using the Java Runtime Environment or Java Development Kit is at risk. 'Delivery of exploits in this manner is attractive to attackers because even though the browser may be fully patched, some people neglect to also patch programs invoked by browsers to render specific types of content,' said Lowe."
And people called me paranoid (Score:4, Insightful)
To quote Harry Dresden... (Score:5, Funny)
Re:And people called me paranoid (Score:5, Informative)
Re:And people called me paranoid (Score:4, Informative)
Re: (Score:3, Informative)
http://noscript.net/
NoScript blocks JavaScript, Java and other executable content.
How...useful. :/ (Score:5, Insightful)
Okay, so which versions are vulnerable?
Re:How...useful. :/ (Score:4, Funny)
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)
Quoted from
AL-2007.0071 -- [Win][Linux][Solaris] -- Sun Java Runtime Environment vulnerability allows remote compromise [auscert.org.au]
1. Impact
A buffer overflow vulnerability in the image parsing code in the Java
Runtime Environment may allow an untrusted applet or application to
elevate its privileges. For example, an applet may grant itself
permissions to read and write local files or execute local
applications that are accessible to the user running the untrusted
applet.
A second vulnerability may allow an untrusted applet or application to
cause the Java Virtual Machine to hang.
Sun acknowledges, with thanks, Chris Evans of the Google Security
Team, for bringing these issues to our attention.
These issues are also referenced in the following documents:
CVE-2007-2788 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
CVE-2007-2789 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
Re:Original AusCERT (Score:5, Informative)
Bunch of FUD-spreading fear-mongers. Hrumph.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing library.
not FUD (Score:3, Informative)
According to the announcement, it allows applets to elevate their privileges.
Bunch of FUD-spreading fear-mongers. Hrumph.
If applets are vulnerable, that's not FUD, it's serious. Of course, it's only the latest in several such vulnerabilities over the years, which is probably why many people just disable Java.
Oh, and Sun wouldn't have had this problem if they'd used pure Java code rather than relying on an existing li
Re:not FUD (Score:4, Interesting)
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.
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:Original AusCERT (Score:5, Informative)
No, it doesn't. First off, I guarantee you that J2ME implementations do NOT use the same parsing library as the desktop JVM. It's far too heavyweight. Add to that fact that the embedded implementations are written by the phone vendor, significantly decreasing the risk.
Secondly, J2ME does not support JPEGs or BMPs. The standard only supports PNGs. If you want to open JPEGs, you have to use a pure-Java decoder. (Which would not be vulnerable.)
Thirdly, Java applet support is extremely limited in Symbian devices; the only devices I'm aware of that support applets. It's basically Java ME + a few extra APIs to bring it up to Java 1.1 standards. It's doubtful that these VMs even contain the APIs that are being exploited here.
Oh dear, where are my manners? I'd also like to thank the poster for finding the relevant AusCERT article. Without it, we'd still be at the FUD level.
Re:Original AusCERT (Score:4, Funny)
I mean, C is just portable Assembler, right? If C is the source of all them evil buffer overflows, I reckon that means Assembler's got 'em, too?
Heck: me an' Jethro wuz wonderin' how these here computers ever got far enough along for the Sun to 'shine and the Java to perk.
Yep. I reckon only them city slickers with all their fancy talk do anything but Java anymore, buncha used car salesmen.
JVM in Java (Score:4, Informative)
So if your JVM includes a JIT, it is not so farfetched for it to be "pure" Java. (The privileged bytecodes are an extension to the Java standard.) Such a design eliminates whole classes of common bugs. Unfortunately, there are infinitely many additional classes of bugs to take their place. One reason why production JVMs are still coded in C is that the code generation of mature C compilers is so much better than a first generation JIT.
Re: (Score:2, Interesting)
Re:Original AusCERT (Score:5, Insightful)
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 can't write the whole thing in Java (Score:3, Informative)
I have to admit that I have been very impressed by the overall security of Java. The design is not inherently safe, so the implementation has to be flawless, and I was extremely skeptical of this approach... but Sun has done an excellent job of implementing the Java security model in Java itself with untrusted code running in the same fully capable virtual machine as trusted code.
This means that for untrusted code, implementing as mu
Re:Original AusCERT (Score:4, Informative)
And how? (Score:4, Interesting)
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: (Score:2)
Re:And how? (Score:4, Informative)
Most folks who've worked in small-to-medium businesses or less critical environments (such as education) simply can't comprehend the hell that is trying to coordinate a release to such a large community.
You're right, I can't... (Score:3, Insightful)
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)
'Virtually Everything' or 'Everything Virtual'? (Score:5, Funny)
You forget... (Score:5, Funny)
Re:You forget... (Score:5, Funny)
Re:You forget... (Score:5, Interesting)
I know. (Score:4, Insightful)
Re:You forget... (Score:5, Insightful)
Re: (Score:2)
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... (Score:5, Insightful)
Re: (Score:3, Informative)
Re:You forget... (Score:5, Funny)
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)
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)
Re:You forget... (Score:5, Insightful)
Re:You forget... (Score:5, Funny)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
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.
Re:'Virtually Everything' or 'Everything Virtual'? (Score:5, Funny)
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? (Score:2)
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: (Score:3, Funny)
Re:Are you sure? (Score:5, Funny)
Re: (Score:2)
> 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)
Re: (Score:2)
OMG, OMG, Did you Read the Article? (Score:2)
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.
Extraordinary claims require extraordinary proof (Score:5, Insightful)
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 (Score:5, Informative)
I find it interesting that this team is supposedly reporting a major flaw, yet manually running the Java updater finds no new JVM versions to download. Didn't they contact Sun first? Shouldn't there be a patch already? Meh. The whole thing stinks.
If you want to run the updater yourself, you can either right-click on the Java icon in your taskbar and select "Control Panel", or you can run the "javacpl.exe" file in the "c:\Program Files\Java\jre\bin" directory. Look under the "Update" tab to see the update schedule. Click "Update Now" to check for the lastest release.
Mac users do not need to access a separate updater. Java updates are pushed through the standard system updates, accessible through the control panel. These are also scheduled to run on a regular basis. Only Linux/Unix users should need to manually update their JVMs if and when a patch becomes available. Some of these OSes do have a Java updater, but I don't know the current details about these.
Re: (Score:2)
Re:Extraordinary claims require extraordinary proo (Score:2)
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
Re:Extraordinary claims require extraordinary proo (Score:5, Informative)
No, as others have pointed out it's a flaw in JPEGs and BMP files. PNGs (pretty much the only format used in J2ME in cell phones and PDAs) are safe. Here are the advisories:
http://www.auscert.org.au/render.html?it=7664 [auscert.org.au]
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
The biggest concern is that arbitrary applets could be pushed to user's machines. This is mitigated by the fact that the latest JVM's have already been repaired. Thanks to the Java autoupdater, there should not be many desktops at risk.
A secondary concern is servers that accept image uploads. BMPs are usually not accepted anyway, but JPEGs could be a concern. So it is best to upgrade these. Which brings us around to your concern...
For one, it is possible to upgrade these JVMs. It's a bit trickier than a standard install, but it can be done, at least inside the same VM version. (e.g. Java 1.4 apps will usually not suffer from an upgrade to 1.4.1, but a Java 5 upgrade would be disasterous.)
Secondly, I *DO* have a solution. Yell at the vendor! If they're going to stupidly integrate the JVM for no reason other than to make your life difficult (ostensibly to make it easier, yeah right) then they can take the burden of getting you a patch. Don't let the vendor off the hook until they get the problem fixed! That's just good practice, nothing to do with Java.
(Of course, a better practice is to find a vendor who doesn't stupidly integrate JVMs, but I digress.)
BTW, are you talking about Oracle AS or Oracle Database? Oracle AS would need to be patched for situations like this just in case you handle or will handle image uploads. Oracle Database would not be at risk since there is almost no chance of the database being made to parse images in its procedural code. Desktop applications are similarly unaffected unless they download arbitrary images from the internet.
Re: (Score:2)
So what's the problem again?
Re: (Score:2)
And this, ladies, gentleman, scum, and bots, is why portability is important to security.
The sky is falling (Score:2)
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 (Score:5, Informative)
I see at the top where they mention the Google security team. But the article quotes only someone named Chris Gatford from "penetration testing firm Pure Hacking" and someone from "Australia's Computer Emergency Response Team"
AUSCERT ^ has issued something on this, but there is not many details. They claim the exploit is the ability for applets to escalate privileges.
Also, someone asked, but here are the versions they claim are vulnerable, for windows and solaris.
And a link to the Aussie security alert [auscert.org.au]
TFA is extremely vague (Score:5, Insightful)
use Fedora 7 (Score:2)
For the Very Low Price of .... (Score:2, Funny)
For an additional undetermined sum, Pure Hacking will offer an ambiguous and nefarious fix for the vulnerability.
here is the security flaw (Score:3, Interesting)
http://groups.google.com/group/ph4nt0m/msg/05b113
Re: (Score:2)
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)
More information (Score:3, Informative)
Doh, ignore the above :-) (Score:3, Funny)
Ubiquitousness? (Score:4, Funny)
Ah! That would be 'ubiquity' then?
FFS editors!
Re: (Score:2)
Re: (Score:2)
Dumb people think their words carry more weight if they add a few syllables.
The Fearmongering... (Score:2)
I agree, but, since when has patching been easier on something else?
Re: (Score:2)
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
Re: (Score:2)
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
SOD - Superstition Obfuscation Demagoguery (Score:2, Funny)
Sounds like a warning from 'Homeland Security' (Score:3, Insightful)
The article has no information what so ever - but, perhaps that is to avoid spreading information on how to exploit this alleged weakness.
Re: (Score:2)
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.
Well, since this impacts Java... (Score:5, Funny)
Re: (Score:2)
Fixed in JRE 5 Update 12? (Score:2)
Re:Fixed in JRE 5 Update 12? (Score:5, Informative)
* JDK and JRE 6 Update 1 or later
* JDK and JRE 5.0 Update 11 or later
* SDK and JRE 1.4.2_15 and later
From:
http://www.auscert.org.au/render.html?it=7664 [auscert.org.au]
AusCERT alert. (Score:2)
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)
Nothing on Google's Security Blog (Score:2)
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: (Score:2)
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!
It's a C/C++ flaw in the Java environment. (Score:2)
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).
Re:It's a C/C++ flaw in the Java environment. (Score:5, Insightful)
Would you really suggest that it's better to train people to not cut their fingers off using table saws than to get them to switch to table saws with some sort of finger guard? Yeah, it's not that the unprotected ones are at fault if you slip up and slice your pinky off, but it seems perfectly reasonable to avoid the problem altogether with a little prior consideration at the tool level, especially if the extra safety modifications are easy. Though to be fair, in this case I don't know what the "best" alternative to C is, since most of the real popular languages these days are interpreted either entirely or at a byte-code level, so are somewhat slow.
Perhaps..... (Score:2)
Beware of giving out specifics! (Score:2)
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
No Problem (Score:2)
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
fine print: sponsored by MSFT (Score:2)
And SuSE has a patch and details. (Score:3, Informative)
Update Version: 3832-0
Category: Security
Status: Needed
The Sun JAVA JDK 1.5.0 was upgraded to release 12 to fix
various bugs, including the following security bugs:
CVE-2007-2788 / CVE-2007-3004: Integer overflow in the
embedded ICC profile image parser in Sun Java Development
Kit (JDK), allows remote attackers to execute arbitrary
code or cause a denial of service (JVM crash) via a crafted
JPEG or BMP file.
CVE-2007-2789 / CVE-2007-3005: The BMP image parser in Sun
Java Development Kit (JDK), on Unix/Linux systems, allows
remote attackers to trigger the opening of arbitrary local
files via a crafted BMP file, which causes a denial of
service (system hang) in certain cases such as
and has other unspecified impact.
CVE-2007-0243: Buffer overflow in Sun JDK and Java Runtime
Environment (JRE) allows applets to gain privileges via a
GIF image with a block with a 0 width field, which triggers
memory corruption.
Just my luck... (Score:4, Funny)
Lava Flow (Score:4, Funny)
Java version used by your broswer (Score:3, Informative)
http://www.javatester.org/version.html [javatester.org]
According to AusCERT, http://www.auscert.org.au/render.html?it=7664 [auscert.org.au]
you are vulnerable, if your JRE is:
- Sun Java Runtime Environment (JRE) 6
- Sun Java Runtime Environment (JRE) 5.0 Update 10 and prior
- Sun Java Runtime Environment (JRE) 1.4.2_14 and prior
- Sun Java Runtime Environment (JRE) 1.3.1_20 and prior
TFA tells us "Virtually nothing" (Score:3, Interesting)
java updater gives me nothing (Score:3, Funny)
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)
J2SE Runtime Environment 5.0 Update 11
Java(TM) SE Runtime Environment 6 Update 1
Java(TM) 6 Update 2
What will the next update be called? J2SE Runtime Environment 6.0 Update 3?
Installer changes every time, too. It is just inconvenient for those that want to do unattended installs.
Re: (Score:2, Insightful)
If you're paranoid, at least disable the right thing.
Re: (Score:2)
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: (Score:2, Insightful)
How many times have we seen this comment...
Re: (Score:2)
Re:Anyone have details? (Score:5, Funny)
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.
Re:Is Apple affected? (Score:4, Funny)