No Java component has had a bigger bull’s eye on its back this year than the Java Reflection API. Bug hunters and hackers alike have found a number of zero-days related to the Reflection API, most of which enable the remote execution of code outside the Java sandbox that’s supposed to prevent such an action.
“[The] Reflection API doesn’t fit the Java security model very well. The problem is that by design it relies on a caller for various security related decisions. And the caller can be impersonated if the API is not used in a secure manner,” said Java bug hunter Adam Gowdiak, CEO of security company Security Explorations of Poland. “Reflection API calls are very frequent in [the] Java codebase. Many of them were implemented in insecure fashion, thus [the] large number of issues.”
Gowdiak reported another issue to Oracle yesterday, along with proof-of-concept code that targets an unreported flaw in the Reflection API introduced into Java Standard Edition 7. The flaw, he said, can be exploited using an attack that dates back to 2002; the current proof of concept he developed beat the latest version of Java, 7U25. The result was another reliable sandbox bypass, this time by beating a fundamental feature of Java VM security, the type system, Gowdiak said.
Values in Java, for example, are assigned to one of four types: primitive; null; array; and class, according to the College of Computer and Information Science at Northeastern University. The goal of the type system, Gowdiak said, is to ensure that no illegal memory access to the underlying operating system could be gained by untrusted Java code.
Gowdiak would not disclose details on the vulnerability, nor the attack other than to say it is not as common a threat as it was a decade or more ago.
“The [bigger] surprise is that it was missed at the time the new Reflection API was introduced to Java SE 7,” Gowdiak said. “It should not be a problem for Oracle to fix it. The attack is known and proper support to guard against it already exists in the Java VM.”
Oracle has taken major heat in 2013 for the problems attackers have exploited in a number of targeted attacks. To its credit, Oracle has not stood still and thrown up its hands in surrender to Java insecurity. In April and May, Oracle announced enhancements to the platform it hopes will stem the tide of attacks, in particular against the Java sandbox.
Recent Java updates have brought about changes that prevent unsigned applets from executing by default. Users also see enhanced security warnings about potentially malicious applets and configurations that restrict what older Java versions can do. While signed applets do limit the effectiveness of some malware, it’s been proven that attackers don’t have much of an issue getting their hands on stolen digital certificates that validate malicious applets as legitimate.
“Previously, signing applets was only used to request increased application privileges. With this update, signing applets establishes identity of the signer, but does not necessarily grant additional privileges,” said Oracle’s Nandini Ramani, head Java developer. “As a result, it is now possible to run signed applets without allowing them to run outside the sandbox, and users can prevent the execution of any applets if they are not signed.”
The reception for those changes has certainly been mixed, and the emergence of a decade-old attack that is still relevant today won’t help matters much.
“If Oracle had any Software Security Assurance procedures adopted for Java SE, most of simple reflection API flaws along with a known, 10+ years old attack should have been eliminated prior to Java SE 7 release,” Gowdiak wrote on Full Disclosure. “This didn’t happen, thus it is reasonable to assume that Oracle’s security policies and procedures are either not worth much or their implementation is far from perfect.
“That thought alone should catch attention of Oracle customers not necessarily relying on Java SE, but rather on other Oracle products, which were likely the subject to the very same, questionable Software Security Assurance policies and procedures as Java SE 7,” Gowdiak said.
