Microsoft can take some solace that it is not alone in sending out security updates that don’t fully address a zero-day vulnerability. A researcher at Immunity Inc., put Oracle on a similar hot seat this week when he reported that a recent out-of-band Java update repaired only one of two Java flaws being actively exploited.
Esteban Guillardoy said the Java 1.7 u11 update was incomplete and cautioned that new exploits could easily pair another zero-day with the remaining unpatched vulnerability and kick off a new spate of attacks.
“An attacker with enough knowledge of the Java code base and the help of another zero day bug to replace the one fixed can easily continue compromising users,” Guillardoy said.
Meanwhile, IT managers are caught in the middle of a patch management mess. Since the start of the year, not only have a rash of unreported vulnerabilities been exploited in high-profile attacks, but vendor patches or workarounds have fallen short.
Microsoft’s temporary Fix It for a zero-day in Internet Explorer that was being exploited in watering hole attacks was quickly bypassed by researchers at Exodus Intelligence. Users of IE 6-8—still the largest install base of the browser—were exposed as early as Dec. 7 when websites serving exploits were first detected; they were publicly reported shortly after Christmas Day. Microsoft made its Fix It available Dec. 29; the bypass was reported Jan. 4 and users remained open to attack until an out-of-band patch was released on Monday.
Oracle, meanwhile, won’t have another official Java security update release until Feb. 19. Security Explorations of Poland, a research firm known for its work on Java vulnerabilities, said it reported flaws to Oracle in April and September of last year that still have not been patched.
Oracle may have another zero day to add to its list for February as well. Security blog Krebs on Security reported yesterday another exploit for a different zero day was being sold on a limited basis for $5,000. The blog reported that two versions of the exploit were available—weaponized and source code—and that the sale would be limited to two buyers. A post on the underground forum where this was observed said the new exploit had not been included in any exploit kit, unlike the previous Java zero day which was included in all the major packs including Blackhole, Cool, Nuclear Pack and others. The post has since been removed from the forum, likely indicated the sale is over.
In the meantime, Oracle has to shore up the Java vulnerability it thought had been patched in 7u11. The Oracle patch was believed to have addressed two vulnerabilities, both covered by CVE-2012-0422. According to Oracle’s Java SE documentation, one of the bugs involves reflection, which enables Java to discover information about the constructors and other devices in loaded classes and to operate on underlying counterparts within security restriction. The API, Oracle said, is the go-between for applications.
The second vulnerability in question is in the MBeanInstantiator, a flaw that when used with the reflection API with recursion bypasses a security check, the Java sandbox. It is the MBeanInstantiator vulnerability that Immunity’s Guillardoy said has not been addressed in the update.
“The patch (which is Java 7 update 11) doesn’t show any difference at all in the classes inside com.sun.jmx.mbeanserver package,” he wrote. “It appears then that the MBeanInstantiator.findClass vulnerability is still there in the latest Java update.”
He said he wrote a simple proof of concept that retrieved restricted Java classes, proving an exploit is still possible.
“Sometimes for everyone involved in the offensive world, you need to look at the patch with special detail, because sometimes the vendor stops the worm/0day exploit with a patch, but doesn’t necessary fix all of the associated problems,” Guillardoy wrote. “And of course, being only human, sometimes the vendor’s team just plain messes up the patch.”
Oracle released Java 1.7u11 on Sunday, four days after exploits were discovered in the wild. The update not only said it addressed vulnerabilities being exploited, but also chanced the default Java security level from medium to high. As a result, any unsigned or self-signed Java applications would no longer run by default and would require a user to approve execution of the applet.
Security experts said it was a good first step, but an attacker could still use social engineering to trick a user into executing a malicious Java applet. Attackers could also steal valid digital certificates and sign malicious applets so that they would run without intervention.
While these Java exploits were targeting Windows machine, Java’s ubiquity on all platforms makes it an attractive target for attackers.
“If you have an exploit for memory issues and the exploit is reliable, you don’t have to code a different exploit for different languages or platforms, it just works everywhere,” said Jaime Blasco, manager of AlienVault Labs. “You will have 100 percent probability of exploiting the target if it is vulnerable to that issue.”
This article was updated on Jan. 17 to clarify that CVE-2012-0422 covers both Java vulnerabilities.
