Polish security research firm Security Explorations announced on Friday that it had submitted two new Java vulnerabilities, along with proof-of-concept code, to Oracle, making it clear that significant security issues remain in Java even after last week's patch. In a post to the Full Disclosure list, Security Explorations CEO Adam Gowdiak said, "We have successfully confirmed that a complete Java security sandbox bypass can be still gained under the recent version of Java 7, Update 11."
This was the final negative development in what was a tough week for Java's reputation. Toward the end of the week, the Java story even intersected in a small way with the week's other large story, the Red October barrage exposed by Kaspersky Labs. An Israeli firm, Seculert, determined that at least one previously identified Java exploit was used in Red October's arsenal of exploit code.
According to a Seculert blog entry:
After investigating the command-and-control servers used in the "Red October" campaign, Seculert identified a special folder used by the attackers for an additional attack vector. In this vector, the attackers sent an email with an embedded link to a specially crafted PHP webpage. This webpage exploited a vulnerability in Java (CVE-2011-3544).
The entry goes on to explain that this vulnerability had been known (as the CVS entry indicates) since 2011 and was, at least theoretically, old news by the time it was compiled into a Java JAR file in February of 2012.
The Seculert analysis came on the heels of DHS continuing to recommend that users disable Java on their computer, even though Oracle issued a patch. The update, issued January 14, said that "new Java vulnerabilities are likely to be discovered. To defend against this and future Java vulnerabilities, consider disabling Java in Web browsers until adequate updates are available." The first two of those "future Java vulnerabilities" surfaced the very next day, courtesy of Security Explorations.
For those who have disabled Java, there is some reluctance to turn it back on any time soon. HD Moore, chief security officer at Boston-based Rapid7 and chief architect of Metasploit, said "the reasoning is that it took Oracle a year just to handlesome of the privilege escalation cases reported by Security Explorations. At this rate, it may be another two years before this class of bugs is fully eradicated from the code base."
Part of the problem with Java, Moore noted, is that the approach it takes with its version of sandboxing is long in the tooth: "The Java sandbox was designed when the threat to desktop users was very different. The current generation of sandboxes (Chrome, Adobe, IE) are implemented one level higher --restricting what the sandboxed process can do and not trying to enforce all of the logic within the runtime itself. Java's sandbox is still of the older variety, all it takes is one logic flaw, or some form of memory corruption, to go from a webpage to running code in the context of the user." He pointed to an example where Windows 8, even though it "made a number of improvements in the area of browser security," still falls prey to the current Java flaws and yields a remote shell.
Significant security issues notwithstanding, experts said that asking IT to walk away from Java for any length of time isn't necessarily doable.
Hilik Kotler, co-founder and EVP of product development for Promisec, said recommending that key software tools simply be abandoned isn't a workable strategy. "This week it's Java, but two weeks ago it was Internet Explorer, and two months ago it was Adobe that couldn't be used safely." Kotler believes that managing vulnerabilities shouldn't mean changing the work environment that one's employees are used to. Recommending that software not be used, he said, "is the easiest solution when you don't have the right tools."
No comments:
Post a Comment