Oracle has released a software update to fix a critical security vulnerability in its Java software that miscreants and malware have been exploiting to break into vulnerable computers.
Java 7 Update 11 fixes a critical flaw (CVE-2013-0422) in Java 7 Update 10 and earlier versions of Java 7. The update is available via Oracle’s Web site, or can be downloaded from with Java via the Java Control Panel. Existing users should be able to update by visiting the Windows Control Panel and clicking the Java icon, or by searching for “Java” and clicking the “Update Now” button from the Update tab.
This update also changes the way Java handles Web applications. According to Oracle’s advisory: “The default security level for Java applets and web start applications has been increased from “Medium” to “High”. This affects the conditions under which unsigned (sandboxed) Java web applications can run. Previously, as long as you had the latest secure Java release installed applets and web start applications would continue to run as always. With the “High” setting the user is always warned before any unsigned application is run to prevent silent exploitation.”
It’s nice that Oracle fixed this vulnerability so quickly, but I’ll continue to advise readers to junk this program altogether unless they have a specific need for it. For one thing, Oracle tried (and failed) to fix this flaw in an earlier update. Also, it seems malware writers are constantly finding new zero-day vulnerabilities in Java, and I would not be surprised to see this zero-day situation repeat itself in a month or so. Also, most users who have Java installed can get by just fine without it (businesses often have mission-critical operations that rely on Java).
If you need Java for a specific Web site, consider adopting a two-browser approach. If you normally browse the Web with Firefox, for example, consider disabling the Java plugin in Firefox, and then using an alternative browser (Chrome, IE9, Safari, etc.) with Java enabled to browse only the site(s) that require(s) it.
Finally! Thanks for the heads-up! 🙂
I wouldn’t get too excited or comfortable.
Per ZDNet:
“Security researcher Adam Gowdiak from Security Explorations has been keeping an eye on the software flaws in Java over the past year. Once Gowdiak analyzed the latest update to Java, he found that the patch still leaves a number of “critical security flaws,” according to Reuters. This statement, mirrored by AlienVault Labs’ Jaime Blasco who branded Oracle’s offering as a “mess,” was later reinforced by the firm’s recommendation against using the software.”
http://www.zdnet.com/security-experts-on-java-fixing-zero-day-exploit-could-take-two-years-7000009756/
Well, the update took except now there is no icon to access Java from the Control Panel!
Assuming Windows is your OS, search for “javacpl.exe”, usually found in C:\Program Files\Java\jre7\bin or C:\Program Files (x86)\Java\jre7\bin.
Yep. Covered this in the Q&A I published on Saturday:
Q: I’m pretty sure that my Windows PC has Java installed, but I can’t seem to locate the Java Control Panel from the Windows Start Menu or Windows Control Panel. What gives?
A: According to CERT’s Dormann, due to what appears to potentially be a bug in the Java installer, the Java Control Panel applet may be missing on some Windows systems. In such cases, the Java Control Panel applet may be launched by finding and executing javacpl.exe manually. This file is likely to be found in C:\Program Files\Java\jre7\bin or C:\Program Files (x86)\Java\jre7\bin.
All I had to do is logon to the Administrator account and voila! Java popped up and updated automatically. Without these articles I would have been pretty late to the table. I really appreciate Brian’s time here! 😀
Too bad File Hippo doesn’t work on the limited rights side anymore. I guess I need to adjust the permissions on it. Secunia PSI would eventually get around to it; but it is usually a week late!
I’m very confused about Mac OS X. I have two machines, Snow Leopard and Lion. The java.com web site does not seem to readily indicate which version of Java I have on either machine. Downloading and running jre-7u11-macosx-x64.dmg seems to install Java v7u11, but Spotlight does not indicate this. (Spotlight does list Java Visual VM, which was downloaded when I clicked on Java preferences).
I wish I could readily test the level of the JRE or JDK I have on my Macs, and easily and completely uninstall Java OR easily update to recommended levels.
Luckily, Safari has a preference on the Security tab to turn Java on or off. I turn it on only when a web site requires it. But I don’t always turn it off when I’m done with the web site.
There is no Java entry in my Applications folder, and no Java entry in Safari’s Extensions tab.
I can empathize with you; it was ridiculously hard to keep up with Java/Adobe applications, even on Windows, a few years ago. The web sites don’t make life easy at all! >:-(
To see which version of Java is installed, and whether it is enabled, try javatester.org which runs an applet inside your browser.
For other ways of checking on whether Java is installed and the version see
How to be as safe as possible with Java
http://blogs.computerworld.com/cybercrime-and-hacking/21626/how-be-safe-possible-java
Java 7 is not supported on Snow Leopard. Lion can have either no Java (it shipped without it), only Java 6, only Java 7 or both Java 6 and 7.
If you launched Terminal and type in java -version, it may help you to narrow down which version you’re using.
Well, today, just now, I again looked in the System Preferences for Mac OS Lion (10.7) and found the Java Control Panel. However, it “only made the change for this user,” not the whole system. The thing is (here I hang my head in shame) I am running as the sole user on this system, and of course that user is an admin.
As someone observed, the Java Control Panel is buggy.
I gotta go do something else today rather than this.
The change to prompting is acutaly a big deal improvement: Now ALL Java-in-web will require a user prompt before executing which means, even with a zero-day, the infection rate will be vastly less.
In fact, it now makes Java Zero-days nearly irrelevant, as a zero day on an unsigned applet is a very similar prompt to a signed applet, which is actually requesting full access: if the user says “run” to a rogue signed applet (which, with a CA certificate, is the same ‘default run’ prompting) the attacker has full control anyway.
So if you have to convince the user to select “run” in any case, why bother with a zero day? Just sign your malcode and be done with it…
I see what you’re saying, Nicholas, but I only wish I agreed that this means Java 0days won’t matter going forward.
For several years, once of the most reliable Java “exploits” that many exploit kits have used is to just send a prompt to the user to run a Java applet. It has been quite successful.
Agreed, but this is why zero days don’t matter: since everything is now prompted, why bother looking for a zero day when you can just pay the $200 to sign your code? Looking at the different dialogs for signed vs unsigned code, I can’t see most users telling the difference.
This is a band-aid solution. One can’t rule out the possibility that future exploit may simply disable or surpress the prompting.
That would require two zero-days however, both at the same time: one to bypass the prompting and one to privilege escalate, which is a much harder problem than just one vulnerability.
And since the prompting is very early in the code execution path, before any attacker Java starts running, its going to be far harder to find a vulnerability compared with the privilege escalation vulnerabilities in Java since the code paths are both much smaller and has far fewer attacker-sourced semantics[1].
Getting rid of Java is AMAZINGLY GOOD ADVICE, especially with the everpresent and unremovable architectural flaw that “Signed Code + User says Yes == full ownership” [2]. But the prompting for unsigned code is a huge change in how Java works and the exploitability of Java.
Attackers are economically rational: Far better now to try again for Flash, Shockwave, Silverlight, Acrobat, and individual browser exploits, since those are always-run-unprompted, with Java being targeted almost exclusively with old exploits and “Prompt to P0wn” which no Java patch can fix.
Thus although Java is still a FESTERING PIT OF AWFULNESS THAT MUST BE REMOVED UNLESS ABSOLUTELY NEEDED BECAUSE OF THE SEMANTICS OF SIGNED CODE’S “PROMPT TO P0WN” [3], this change is far more than a simple “Band-Aid”, but a fundamental shift in Java’s attractiveness as an exploit target.
[1] Java in its sandbox for unsigned code is basically like a Unix system with a ton of SUID programs lying around: any single one of these programs which has a flaw results in a privilege escalation attack which is why its a security nightmare. Thus the difficulty in securing the sandbox, there are thousands of code paths that involve Java’s support code having to run at higher privileges, any one of which may have exploits.
[2] This is an architectural flaw that they CAN NOT REMOVE, since this is why you get business critical sites written in Java, like, eg, GoToMeeting’s previous web-based system.
If Oracle made it so signed code ran in the sandbox, it would kill Java on the web completely, since it would both break a ton of existing code and Java would offer no benefit over the more ubiquitous Flash which has comparable semantics to ‘working-sandbox’ Java, and actually has a more-flexible same-origin policy.
[3] Yes, I say this as the developer of a widely used (~3/4 of a million executions), signed-Java network measurement application, which takes significant advantage that signed Java has full privilege. A complete eradication of Java would eradicate our current implementation of Netalyzr. It is a price I am WILLING TO PAY
Nicholas, I’m intrigued by your “prompting” comments. I have seen the behavior on running the applets in v7 Update 11. In the past, I and many others have become conditioned to “Always Run” on various prompts (so you have fewer prompts to deal with in just getting things done on your PC!).
I think the “always run” (aka tick-box for “do not show me this again”) is still available (at least for signed applets), is it not?
And perhaps the tick-box should only exist/be an option for signed applets as opposed to unsigned ones?
Brian is right, malware writers can just sign their code for new zero-day infestations, but at least that puts malware writers “on the grid” for tracing and legal prosecution.
The “Prompt to p0wn” for signed code is still there, and its obscenely dangerous. But there has been a real change for unsigned code of adding a prompt (effectively, now all Java is under NoScript-type functionality).
The unsigned code prompt includes an “Always allow this app” optional checkbox (I think its that JAR + hash, but I don’t know for sure and haven’t verified semantics).
Signed code has always had an “always allow this publisher” (read, signing key) checkbox.
I not sure signing will put them on a grid to tracking; I was always told anyone could sign their own certificate. (?)
Self signed certificates require two “accepts”: The user must select an “OK to run” checkbox AND the “OK to run” button. So its less usable for an exploit than a proper CA certificate.
But CA certificates are worthless protection: You buy em with a stolen or one time use credit card #, and access through a proxy.
Yes, I see – just like they used one of my credit card numbers a few years back to buy just 3 months of command and control space at a disreputable server farm, to control their bot-net. They always have a slippery solution to everything.
Thanks for your input to this discussion! 🙂
Unfortunately, the OC Surf Cam requires java.
And no, I’m not going to stop obsessively checking surf conditions in Ocean City. Even if it is January and the water is 42 degrees.
FTA: “It’s nice that Oracle fixed this vulnerability so quickly…”
I’m not so sure about that.
http://www.cnn.com/2013/01/11/tech/web/java-vulnerability/
They may-have/should-have known about this some time ago.
Hi Jake,
Did you read the rest of that paragraph?
“It’s nice that Oracle fixed this vulnerability so quickly, but I’ll continue to advise readers to junk this program altogether unless they have a specific need for it. For one thing, Oracle tried (and failed) to fix this flaw in an earlier update.”
My point is that there is reason to think that Oracle isn’t being terribly aggressive about fixing security problems.
I agree with your position, but I feel that you were being a bit too kind to Oracle in the first part of your statement.
Brian, FYI, your link in the article points to downloads of the JDK (Java Development Kit). In addition, you should add this link…
http://java.com/en/download/manual.jsp
…(or a similar one) for the JRE (Java Runtime Engine), which IMHO is what most users are interested it.
Also, for any who are interested, here is the link for testing your Java installation:
http://java.com/en/download/testjava.jsp
This link:
http://java.com/en/download/testjava.jsp
does not work on Mac OS X (I tested with Snow Leopard, 10.6), last night, and with Lion, 10.7, today).
Instead, try this one:
http://www.javatester.org/version.html
It recognizes both Safari’s “Enable Java” preference (see the Security tab) and to NOSCRIPT settings when running Firefox.
Thanks for the update, Bob.
Hi Brian,
Do you think you could do an article on how to keep up with software updates?
I’m an administrator for a small company and one of my struggles to knowing when an update comes out. As it stands now the only way I can tell is if an auto-updater notifies me or a user.
Even if it only covers Java and Adobe products that would be a huge chunk of patch management dilemma I’m facing.
Josh, you might try File Hippo’s Update Checker:
http://www.filehippo.com/updatechecker/
You can do a one-time scan with the stand-alone version, or use the installed version to automatically check and recommend updates.
Another tool is Ninite: http://ninite.com/
This one is useful for initial installations as well as on-going checking.
I think subscriptions are required for both products for on-going use.
Thank you Chris,
I’ve decided to do the free trial of Ninite Pro and so far I am impressed. It picked up on the Java/Flash giants on my test machine as well as Acrobat and some of my “toys”. (7-zip, GIMP etc.)
Their smallest package is only $20/mo, which is very worth it in my opinion.
Also Secunia PSI can catch what File Hippo misses, and tracks applications that many not only need to be patched but are end of life, and no longer supported. However File Hippo only alerts you to a patch/update when it is available. Secunia PSI will alert you to vulnerable applications that are still not patched. That can be important if the vendor is unwilling or too late to their obligations.
PatchMyPC is free, although it has to be run manually. It will update Java, Adobe Reader, Adobe Flash, the browsers, and quite a few other programs. I install it on all my clients and tell them to run it weekly or so.
I have bad news, Brian. The emergency patch for Java has failed to fix cybercrime holes, according to experts.
http://www.independent.ie/business/technology/emergency-patch-for-java-fails-to-fix-cybercrime-holes-warn-experts-3351321.html
Do you think I will disable Java again? 🙁
Debbie,
I don’t know anyone who thought this patch would fix things. I have been fairly explicit — in this very blog post and in countless others — for going on three years now that most users have no need to have Java installed, much less plugged in to their Web browsers. If you do not have a need for Java, by all means, uninstall it completely. If you do have a need for it, adopt the two-browser approach that I have outlined in countless stories on this blog, including Saturday’s Q&A.
http://krebsonsecurity.com/2013/01/what-you-need-to-know-about-the-java-exploit/
Java IS used in many places, but you won’t know if/where you’re using it until you uninstall it.
Some places it IS used is TED (Talks — Ideas Worth Spreading), and ClubPogo (games).
If you’re an OpenOffice user, you need Java, but here’s a clear case for using v7.10+’s new ‘disable in browser’ function to protect from Malware, yet maintain stand-alone function for Open Office applications.
I like Brian’s suggestion on the two-browser approach; default browser without Java, and an alternate (preferably more obscure) browser with Java.
Or just keep the download link handy to install it when you need it, and then uninstall it when you’re done.
You don’t need Java for most aspects of OpenOffice – they’re slowly transitioning the retiming Java components to Python 🙂
I’m not 100% clear on one thing. Is it a browser-specific vulnerability?
There’s one desktop app I use for work that was built in Java. It makes no use of the browser or applets.
If I ensure that all browsers have Java disabled, does that basically resolve the issue or are desktop apps also a concern as well?
Hi Rey. I covered this in the Q&A published this weekend
Q: Yikes. How do I protect my computer?
A: The version of Java that runs on most consumer PCs includes a browser plug-in. According to researchers at Carnegie Mellon University‘s CERT, unplugging the Java plugin from the browser essentially prevents exploitation of the vulnerability.
The threat is not from apps installed on your computer. It’s from Java being plugged into your browser.
Thanks. Appreciate the reply and good to know.
There’s always a concern, but if you turn off Java in all the browsers AND have really good security software, you should still be able to run Java for your desktop apps.
The danger from the exploit kits has to do with visiting a maliciously infected website which can dump malware code onto your machine without you noticing.
If your desktop app has no interaction with the internet, this SHOULD not occur. But the reason these security holes exist in the first place is that in the pursuit of functionality and usability, someone lacked the vision/imagination to speculate how functions could be misused.
Just look at email and the problem of spam. Today’s spam problem wasn’t envisioned as part of the design; heck SECURITY wasn’t an original design point for what the internet originated from.
Thank you for the reply Chris and very well-said.
Just to add here for an example; I use a version of Chrome by Comodo called Dragon, and I’ve been testing a scriptblocker that another poster recommended on this blog, called ScriptSafe, I think I like it better than No Script on Mozilla’s Fire Fox.
HSA is warning you’re at risk even after the patch: http://www.zdnet.com/homeland-security-warns-java-still-poses-risks-after-security-fix-7000009785/
As Brian has said numerous times, it’s best just to uninstall Java unless you need it. Or at the very least understand what’s needed to disable it in your particular browser.
Ok, just to clarify…I have a desktop app running on my mac that requires java 1.6 to run and it does interact with the internet. Should I be concerned? I have turned off Java in my browsers and also in java preferences; however I would like to use this app in the future.
Thanks for answering all of our questions. Apple sure has been no help on this one.
Java did an update on my PC (win 7) a few days ago, and the plug in wouldn’t work. It told me it was out of date, but I was able to manually start it. Another update today, and now it doesn’t work at all. Looks like a time for “restore”. Any ideas? Perhaps I’ll run Spybot.
Java doesn’t typically work on most web sites for me either, including the test site at Oracle! (Vista x64 w/32 bit IE9)Oddly enough it always seems to work when I really need it on critical sites. [Go figure!] I’ve tried every fix suggested at Oracle and have never got to the bottom of it. Total re-installs of the operating system did NOT work. It has left me wondering if the problem is with the site, and how they implement the server side of the equation. The other factor is that I never know whether it is just the java script plug-in or the Java 7 application that is misbehaving.
You could try using Revo Uninstaller to totally remove Java, then download SpyBHORemover from Major Geeks or File Hippo and forcefully remove the plugin from Internet Explorer. I’ve had to do this for unwanted plugins, and it is a lot easier than other techniques. Then reinstall Java and see if the plugin has refreshed or go to the target site, and perhaps, if this is an active X issue it will download the plugin automatically.
I have read that Microsoft does use active X to run JavaScript plugins, so if I’m wrong, I’m getting misinformation from tech forums across the web.
Sorry R James – now I’m the one brain farting! The following procedure should uninstall the plugin.
1. Launch Internet Explorer and click the “Tools” for IE 7 or “Safety” for IE 8 menu on the top of your Web browser. Select “Manage Add-ons” to launch the IE plug-in management console.
2. Select “All add-ons” under “Show.” You should see a list of Internet Explorer’s ActiveX applications and browser add-ons such as toolbars.
3. Select the plug-in you want to remove and click “Disable” to deactivate it from Internet Explorer. Repeat the same process to disable additional plug-ins. Restart your Web browser. If you want to remove the plug-in completely from IE and your computer, click the Windows “Start” menu and click the “Control Panel.”
4. Click “Program and Features” under “Programs” to launch the programs console if you are using Windows Vista or 7. For Windows XP users, launch the programs console by double-clicking “Add or Remove Programs.”
5. Scroll through the programs console and click the IE plug-in you want to remove and click “Remove/Uninstall.” Click “OK” to confirm and remove the application. Repeat this same process to remove additional plug-ins. Restart your Web browser.
There’s an easy way to disable Java immediately using Group Policy or your own management tool. We have a blog and video to show you exactly how to do it:
http://www.policypak.com/blog/entry/exactly-how-are-you-going-to-turn-off-java-now-in-your-enterprise.html
Java 0-day clarification – the fix does not fix the 0-day, only the current attack vector
If I may beg everyone’s indulgence for a moment I would like to make some possibly overlooked but important points so as to clear up any remaining uncertainty.
The most misunderstood thing seems to be the difference between Java and JavaScript. Java is the actual application that is installed in your PC and has nothing to do with JavaScript, which is what your browser usually uses as an add-on or a plug-in when visiting a website that uses JavaScript to display and operate the page properly.
The biggest danger is when you visit a web page that tells the browser to launch a Java Applet which is like a mini application, and it will indeed use the version of Java installed on your computer. This is why the Internet Explorer Tools| Advanced tab under Java (Sun) has a box labeled ‘Use JRE x.x.x_xx for (requires Restart).’ Unchecking this box, by the way, does not disable Java, but instead merely has Windows make the decision on what version of Java to launch instead of a hard setting in Internet Explorer having the browser make the decision. If you uncheck the box and have multiple versions of Java installed, Windows will pick the Java version that is most appropriate to use for the applet based on what the web server tells it.
Next, let’s look at the current Oracle release of Java7update11 that ‘fixes’ Java 7. Oracle Security Alert CVE-2013-0422 states that Java 7 Update 11 addresses this (CVE-2013-0422) and an equally severe vulnerability (CVE-2012-3174). This statement is not correct. In reality Oracle only changed 15 lines of code designed to mitigate the current 0-day attack CVE-2012-3174. Nothing was done to correct the underlying vulnerability in CVE-2013-0422 which means an attacker still has this to work with; and all he needs to do is mix up a new cocktail and here we go all over again with another 0-day. If you doubt what I am saying, go here – http://immunityproducts.blogspot.ca/2013/01/confirmed-java-only-fixed-one-of-two.html and have a look for yourself.
Finally, I would like to point out that regardless of what you may have read elsewhere, none of these current vulnerabilities exist in Java 6, which incidentally reaches end-of-life next month. US CERT has even said: “OpenJDK 7, and subsequently IcedTea, are also affected. The invokeWithArguments method was introduced with Java 7, so therefore Java 6 is not affected.”
MBeanInstantiator.findClass vulnerability (CVE-2013-0422) is still there in the latest Java update. Although the MBeanInstantiator code is the same in both Java 6 and Java 7, JDK/JRE 6 cannot be exploited because of additional flags set in the code. The call hierarchy is different in JDK6 and JDK7.
Clearly, Java 6 is safer by far than Java7. In 2012, 50% of all exploits targeted Java as part of the attack vector, and 95% of these targeted Java 7. The last to successfully attack Java 6 specifically was almost a year ago.
In any case, I don’t believe Java can ever really be fixed or properly secured, and in my home lab I have not had it installed in anything since 2000, and have not needed it for anything. Chances are pretty good you don’t either, and if you do (Pogo users comes to mind, but there are others) use Brian’s recommended two-browser approach for only those sites that require it.
As a parting thought; browsing the internet, checking email etc. is best done only from a limited privilege account so nothing needing administrator permissions can execute and install to begin with – everyone does this, right?
Except that they made one other huge change in 7.11: Now ALL applets required prompting. Period. This is a huge fix, because it changes the whole economics of Java Zero-Days and exploiting java. It is this, not patching the particular exploit, that is the major change, and should have been done a decade ago…
Before, you cook up a zero day, and a web browser with Java visits it and the user is p0wned. Now the user is faced with a prompt of “do they allow this to run”.
But perhaps the biggest flaw of Java is that signed Java code always had a “prompt to run” model, and, when the user said “yes”, the Java code runs with full user privilege: no exploit required.
So since now ANY Java exploit requires the user to say “yes”, why bother with any Java exploit? Just sign your code and, if the user says “Yes”, you have owned them.
The advice to ditch Java’s browser plugin completely is a really good one, and remains really REALLY good advice, because this “One click and the user p0wns himself” is a fundamental flaw (and legitimate feature) and remains with Java.
But if you have to have Java in the browser (e.g. Go To Meeting’s browser interface, amongst others), now you can without worrying about a silent driveby attack.
And attackers aren’t going to bother hunting for Java zero days except for bragging rights, as they are now no more useful than any valid code signing certificate when it comes to exploiting users.
Okay –
So you’re saying that if it is not a zero day, the signature ID of the malware doesn’t matter – right? So when the user says yes – the anti-malware solution will not be fast enough to put the hammer down on the process?
Most of the AV/AM solutions I use test way faster than even the zero day threats can react during the processing environment run time. Some of my HIPs react even to zero day threats, and DON”T NEED a definition/signature to stop the behavior.
But you’re saying this isn’t so? Just wondering. 🙂
What is amusing (and irritating) to me is the battle going on between “the experts” over disabling Java (or any other insecure technology).
First we have “the experts” telling us to disable Java.
Now we have push back from “the experts” claiming that the first “experts” are wrong because companies need to have Java (or whatever other technology, such as older IE) installed for corporate reasons and therefore telling people to “dump it” is bad advice. They claim that other “mitigation” measures are better.
The reality is that both sides are wrong. What needs to happen is for corporations to realize that every technology is insecure and to stop locking themselves into insecure technologies such that they CANNOT “dump” them when proven to be insecure.
This of course is a “Catch 22” situation – because all technologies are insecure and yet corporations “have to” commit to writing apps or buying software from companies that lock them into a given technology.
What I question is the “have to” mentality that corporations seem to have.
So we’re back to my meme: “There is no security. Deal.”
What irritates me is this back and forth between “the experts” who appear to be using this issue as a means to differentiate themselves in the industry, not to actually help the end users.
It’s amazing for me to have a site, which is helpful designed for my knowledge. thanks admin
man this blog is actually neat i love looking at your site content carry on the nice perform!