Oracle Patch Exploit
Versions: ALL

Overview
Consider the following question with care.

Who are the first people to access Oracle's Support website and download the latest CPU (Critical Patch Update)?

There is a good chance it is not operations DBAs that will immediately deploy it in production.

How long does your organization take from the instant a CPU is released to:
  • Download it?
  • Install it in a dev environment?
  • Install it in a test environment?
  • Get approval to take an outage?
  • Schedule the outage?
  • Wait for the date and time scheduled?
  • Apply the CPU to every database in production?
Based on hundreds of interviews with DBAs it appears the answer is measured in months not minutes or hours.

So who, absent the normal bureaucratic overhead, downloaded, read the notes, and installed it before you did?

The hackers.

In the Exploit Demo section we will walk you through an example of how it might work using a real CPU.
 
Exploit Demo
Consider the page from MyOracleSupport at the right.

At the bottom of the page, highlighted in red, is the "Known Issues" section.

If you want to attack Oracle Databases it is remarkably helpful to learn about issues that you know most of Oracle's customers won't patch for weeks or months: An issue highlighted at OpenWorld 2016 by Larry Ellison during one of his keynotes.
We have highlighted one of those "Known Issues" ... number 17600719 ... because a Core Dump can potentially be used to create a Distributed Denial of Service (DDOS) attack.
So the first thing we did after identifying a possible avenue of attack is learn more about DBMS_UTILITY and the INVALIDATE procedure.

We discovered, for example, we only needed the OBJECT_ID to invalidate it. That would be easy to get.
Then we looked at what permissions we would need to execute the INVALIDATE procedure in Oracle. Looks like anyone with CREATE SESSION can do it as Oracle granted EXECUTE to PUBLIC.
The next step was to test it out because even if we have no clue how to create a core dump ... we may know how to invalidate an object in our schema if the application we are using is poorly designed like so many of them.

First we created a table named TEST.

Then a stored procedure named TESTPROC.

And we easily obtained TESTPROC's object_id (see the code in the red box).
With a single line of code, highlighted in the red box we invalidated the stored procedure.

We validated that TESTPROC was invalid by querying user_objects.

And noted that if TESTPROC had also had dependent objects they too would have been invalidated.
 
Conclusion
Nothing on this page is intended to be critical of Oracle. We wish we could say the same of many of Oracle's customers whose IT processes and procedures make hacking easy.

What Oracle needs to correct is that almost none of the functionality in the DBMS_UTILITY package belongs in the hands of a user that does not have escalated privileges. EXECUTE on the DBMS_UTILITY package should be responsibly granted to applications or to members of the DBA team but not to everyone with a user-id.

Oracle has partially mitigated the risk by definubg DBMS_UTILITY with AUTHID DEFINER. With AUTHID DEFINER, a user with the EXECUTE privilege granted on an object cannot invalidate it with DBMS_UTILITY.INVALIDATE which will protect objects like STANDARD from the average user with the CREATE SESSION privilege.

Unfortunately, a lot of applications are poorly designed and users that connect do so directly to the application schema. If you have an application like this then the application's PL/SQL objects can be taken out by any user with access to a command line tool or that can execute a SQL Injection attack.

Related Topics
DBMS_UTILITY