Broadband Tech > Security > Security > Warning: 0-Day vulnerability in Java 7

Warning: 0-Day vulnerability in Java 7

quote:

---

The current version of Java contains a serious security hole that allows computers to be infected with malicious code when a specially crafted web page is visited. The hole is already being exploited in the wild – although currently only for targeted attacks. But since an exploit is now in circulation, it shouldn't be long before criminals exploit the vulnerability for large-scale attack waves

The H's associates at heise Security have managed to recreate the problem and have built a proof-of-concept page using information that is publicly available. When the page is accessed, the Java plugin executes a process, in this case calc.exe, without requesting any prior confirmation. Instead of launching the calculator, the web page could have downloaded and executed a malicious program...cont'd

---

"Small effort with a large security gain: in Firefox, disable Java in the Add-ons menu under Plugins"
»www.h-online.com/security/news/i···m;zoom=2

From Brian Krebs

quote:

---

Attackers have seized upon a previously unknown security hole in Oracle’s ubiquitous Java software to break into vulnerable systems. So far, the attacks exploiting this weakness have been targeted and not widespread, but it appears that the exploit code is now public and is being folded into more widely-available attack tools such as Metasploit and exploit kits like BlackHole.

---

reply to chachazz
At least it not Adobe Java otherwise we'd have patches every week.
--
Don't feed trolls--it only makes them grow!

reply to chachazz
Just pulled 6u33 from all machines until patched JRE versions come out.

6 was not affected.

Well now that I uninstalled it screw it anyway.

I'm not going to miss it all the zero times I typically need to run JRE.

There will be another security patchlevel of JRE 6 in a couple weeks anyway.

reply to therube

reply to therube

quote:

---

New Java zero-day vulnerability has been spotted in the wild. We have seen this unpatched exploit being used in limited targeted attacks. Most of the recent Java run-time environments i.e., JRE 1.7x are vulnerable. In my lab environment, I was able to successfully exploit my test machine against latest version of FireFox with JRE version 1.7 update 6 installed.

---

quote:

---

The vulnerability is present in the Java Runtime Environment (JRE) version 1.7 or later, Atif Mushtaq of security firm FireEye reported on Sunday, while PCs with Java versions 1.6 or earlier installed are not at risk.

---

siljaline, thanks for the information.. regarding whether or not "java 6" is vulnerable, aside from the "register"-article's saying that it is not vulnerable, i have not seen any confirmation of that..

p.s. if "java 6" actually isn't vulnerable, how come all of the articles regarding this issue say to disable java, or uninstall it, rather than saying to switch from "java 7" to "java 6", to resolve the issue?

quote:

---

The current version of Java contains a serious security hole that allows computers to be infected with malicious code

---

Part II Java 7 0-Day vulnerability analysis

quote:

---

Considering that Rapid 7 posted a working exploit and addition to the exploit packs is imminent (Attackers Pounce on Zero-Day Java Exploit by Brian Krebs), plus other analysis articles are being published such as New Java 0day exploited in the wild -by Alienvault, we decided that witholding details of the exploit will not offer additional protection but only hinder development of protection and signatures.

As we mentioned earlier, we contacted Michael Schierl,, the Java expert who discovered a number of Java vulnerabilities and asked him to have a look. He sent back his detailed analysis, exploit source, the interim patch with the source code of the patched class.

---

quote:

---

~ The real vulnerability seems to be inside the new Java7 class com.sun.beans.finder.ClassFinder which seems to make it possible for untrusted code to get access to classes in restricted packages (i. e. packages that are part of the security implementation itself and where usually untrusted code cannot get either access or call it).

~This method of abusing restricted package permissions is new to me (it does not work in Java 6 either as GetField was private there); but it is not unique - there are several ways you can use to get out of the sandbox if you have access to restricted packages - usually they need abit more code though.

---

reply to chachazz
thanks chachaz..

reply to chachazz
I have Java 6 update 7 (still says "Sun" on the about tab).

I don't see how all these security folks can say that Java is not needed. Do all internet users except myself have perfect speed at all times from their ISP? If not, then Java is needed as the ONLY decent speed tests are Java based. Plus, I have an application that I bought that requires it. I'm sure envious of all these folks with perfect speed all the time...wow.
--
When governments fear people, there is liberty. When the people fear the government, there is tyranny. Thomas Jefferson

reply to chachazz
Just tested this with Metasploit against Ubuntu 12.04 in a VM. It worked. However, when I enabled the default AppArmor profile for Firefox, it stopped the exploit cold. This profile is included in Ubuntu but is *not* activated by default. Of course even if the exploit succeeded it wouldn't have root, thus would probably be detected eventually by a discerning user.

What it does is try to run an executable from /tmp, but the AppArmor profile denies it access so it stops there.

Also, it doesn't appear to work against OpenJDK (the open source version of Java). Ubuntu does not package regular Oracle Java by default, so most people are probably using OpenJDK anyway.

Same thing on Chromium browser. The exploit works until I activated the AppArmor profile (and made some tweaks to it of my own). I suppose Java doesn't run in Chromium's built-in chroot sandbox.
--
Getting people to stop using windows is more or less the same as trying to get people to stop smoking tobacco products. They dont want to change; they are happy with slowly dying inside. -- munky99999

reply to chachazz
It's like Java is the new ActiveX.

So would disabling the Java browser plugin stop this exploit?

Also, would putting Microsoft EMET to work on the browser help mitigate the exploit?

reply to chachazz
Curious as to how Chrome is vulnerable if it doesn't even allow java to run unless manually given permission

reply to Mele20