Java Reflection API Woes Resurface in Latest Oracle Patches

Oracle’s Critical Patch update addresses 154 vulnerabilities, many of which are remotely exploitable. Security Explorations of Poland, meanwhile, published details on a number of Java flaws in the Java Reflection API.

Problems with the maligned Java Reflection API, the molten core of far too many exploited Java vulnerabilities in 2013, have surfaced again.

Researchers with Security Explorations yesterday published details of a number of critical vulnerabilities in Java; the disclosures were made on the same day Oracle released its Critical Patch Update, a quarterly monster patch release addressing security issues across its product lines.

Security Explorations CEO Adam Gowdiak said the API in question is often abused by hackers in order to escape or bypass the Java sandbox where suspicious code is supposed to be executed and analyzed before it’s passed on to the underlying operating system or application.

Gowdiak has said in the past the Reflection API, which is supposed to examine or modify apps at runtime in the Java virtual machine, relies on a caller for security decisions that can be spoofed if Reflection is not implemented correctly. Oracle cautions in a Java tutorial: “This is a relatively advanced feature and should be used only by developers who have a strong grasp of the fundamentals of the language … Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it.”

Gowdiak said the proof-of-concept exploits that he and his researchers developed and shared with Oracle allow for not only remote code execution, but also privilege escalation that could allow a hacker to gain the database administrator role for Oracle Database. The proof-of-concept exploits, Gowdiak said, worked against Oracle Database 11g and 12c running on Windows 64-bit systems, Linux x86/x86 64-bit and Solaris x86.

“Java VM and Oracle Database security models do not fit together,” Gowdiak said. “The security model implemented by Oracle Database lacks the advantage of a scoped privilege model with stack inspection introduced into JDK 1.2 and Netscape 4.0 more than 15 years ago. As a result, arbitrary Java code can be successfully injected into a privileged database call sequence.”

Gowdiak said the proof-of-concepts his researchers developed exploit single or chained Java vulnerabilities.

Gowdiak said the proof-of-concepts his researchers developed exploit single or chained Java vulnerabilities that break Java type and memory protections, enabling write-access to memory.

“The actual privilege elevation occurs as a result of a careful manipulation of the content of internal Java VM structures or objects of system classes,” he said. “Privilege elevation techniques (or exploitation vectors) used in our POC codes abuse the implementation of AUTHID DEFINER construct for database procedures and functions defined in a Java language.”

Oracle patched all the vulnerabilities submitted and disclosed by Gowdiak and others; 154 in all. There were 25 Java vulnerabilities, 22 of them allowing remote code execution. Oracle also patched 31 bugs in Oracle Database Server, though only two are remotely exploitable, one of those in the core relational database management system, and another in Oracle Net.

Some of the Oracle Database vulnerabilities include flawed components also found in Oracle Fusion Middleware products. Oracle patched 18 vulnerabilities in that product, 14 of which are remotely exploitable.

Oracle also patched two dozen vulnerabilities in its MySQL database server (nine remotely exploitable vulnerabilities) and 15 in Oracle Sun Systems products, including Solaris and Fujitsu servers. Six of these are remotely exploitable.

Oracle’s Eric Maurice said in a blog post that the company has received reports of Web-based exploits against vulnerabilities that have already been patched in numerous Oracle products.

“Oracle continues to receive credible reports of attempts to exploit vulnerabilities for which fixes have been already published by Oracle,” Maurice said. “In many instances, these fixes were published by Oracle years ago, but their non-application by customers, particularly against Internet-facing systems, results in dangerous exposure for these customers. Keeping up with security releases is a good security practice and good IT governance.”

Suggested articles