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:
The above deficiencies are exploited in our POC codes. The exploitation
scenario implemented by them proceeds as following:
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
References:
[1] Understanding Java Stack Inspection, Dan S. Wallach, Edward W. Felten
http://sip.cs.princeton.edu/pub/oakland98.pdf