Message-ID: <543D847D.2000804@security-explorations.com>
Date: Tue, 14 Oct 2014 22:15:57 +0200
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, fulldisclosure@...lists.org
Subject: [SE-2014-01] Breaking Oracle Database through Java exploits (details)


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

Powered by blists - more mailing lists