Hello All, Oracle Oct 2014 CPU addresses 22 security issues affecting Java VM implementation embedded in Oracle Database software. We have published details of the fixed issues and a description of some privilege elevation techniques abusing a complete Java security sandbox bypass condition for gaining DBA role in an environment of Oracle Database software. All relevant materials accompanied with Proof of Concept codes can be found at our SE-2014-01 project details page: http://www.security-explorations.com/en/SE-2014-01-details.html The codes were successfully tested against Oracle Database 11g / 12c software running on Windows x64, Linux x86/x86-64 and Solaris x86. Published vulnerabilities demonstrate a very well known problem related to Java SE security (insecure use of Java Reflection API). This API was a direct cause for dozens of security issues in Java SE reported to the vendor in 2005, 2012 and 2013. Java exploits make it in particular easy to elevate privileges to an administrator role in the environment of Oracle Database software. This is primarily due to the following: - Java type / memory safety can be broken upon a complete security sandbox bypass. This can be accomplished by the means of Reflection API manipulation or by exploiting a functionality of sun.misc.Unsafe class, - Aurora JVM runs in the same process space and address space as the RDBMS kernel, sharing its memory heaps and directly accessing its relational data, - Java VM and Oracle Database security models do not fit together. The security model implemented by Oracle Database lacks the advantage of a scoped privilege model with stack inspection [1] 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. The above deficiencies are exploited in our POC codes. The exploitation scenario implemented by them proceeds as following: - a complete Java security sandbox bypass is gained with the use of a single or a combination of Java Reflection API issues, - Java type / memory safety gets broken, - arbitrary read / write access to memory is exploited to setup a given database privilege elevation condition. 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. 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. For definer spoofing exploitation vector, successful privilege elevation can occur as a result of a careful manipulation of the content of internal Java VM structures. By changing a field of eoidstkpair_handle structure to the SYS user id value, one can easily spoof the identity of called methods and effectively the identity seen by Oracle Database security engine. If CREATE SESSION is the only privilege available in a target database environment, one can modify the contents of a Java object instance from a privileged (AUTHID DEFINER) system class in order to inject attacker's code into a privileged call sequence. In our case, we set a field of a carefully selected system class to the object instance controlled by an attacker. Arbitrary method dispatch done through such a "spoofed" object results in attacker's code being called with elevated privileges. What's also worth to mention is that one does not need CREATE PROCEDURE privileges in order to define arbitrary Java objects in the environment of Oracle Database software. This privilege is primarily used by a code that integrates Java VM with database structures (class/source/resource handles, database tables, etc.). Introduction of a custom URL handler (jserver:) into Oracle Database Java VM (its class loaders) created an opportunity to load and execute arbitrary Java classes without any privilege checks (Issue 20). We hope that published materials become an eye-opener for all those that were rather skeptic about the impact of Java security vulnerabilities to server environments. Java security issues can pose a significant security risk to any software that relies on a vulnerable Java VM implementation processing untrusted, potentially malicious Java code. Oracle Database is no exceptions here. Thank you. Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to the new level" --------------------------------------------- References: [1] Understanding Java Stack Inspection, Dan S. Wallach, Edward W. Felten http://sip.cs.princeton.edu/pub/oakland98.pdf
