Secure Oracle database binaries by updating JDK

One of the things that gets unnoticed or (overlooked) when securing Oracle Database Infrastructure is securing oracle database binaries by updating JDK build or updating SQL Developer.

When installing Oracle database binaries the version in a database install is always going to be behind the latest JDK so you should update to the latest version since latest version will include security fixes.

to check your current JDK build:

cd $ORACLE_HOME/jdk/bin

java –version

Procedure to replace JDK:

shutdown your oracle database and listener.

cd $ORACLE_HOME

mv jdk jdk.orig

//  you can download the Latest Java SE Patches/Update Releases on MOS (Doc ID 1414485.1) OR All Java SE Downloads on MOS (Doc ID 1439822.1)

//  copy the downloaded JDK to $ORACLE_HOME

scp jdk-6u181-linux-x64.bin $ORACLE_HOME

cd $ORACLE_HOME

./jdk-6u181-linux-x64.bin

cd $ORACLE_HOME

mv jdk1.6.0_181 jdk

rm -rf jdk-6u181-linux-x64.bin

To verify: 

cd $ORACLE_HOME/jdk/bin

java –version

Startup the database and listener.

Run utlrp.sql script and check that all database components are valid:

SQL> @?/rdbms/admin/utlrp.sql

SQL> select * from dba_registry;

Also, check database alert log file …just in case.

If the database has “JAVA” component you can follow the steps described in this procedure for “verification”

How To Determine The JDK Version Used by the Oracle JVM in the Database (Doc ID 131872.1)

Pluggable database Service Level Access Control “Firewall”

If you are using VNC (Valid Node Checking) to implement a TNS firewall in non-CDB Oracle database architecture and wondering if there is a way to perform the same thing in Multitenant Architecture (CDB)…..Yes…through  a package DBMS_SFW_ACL_ADMIN  and its under the account: DBSFWUSER

The account has three tables: ACL$_OBJ , EXADIRECT_ACL , IP_ACL

1

First, you need to add your listener.ora file the following:

LOCAL_REGISTRATION_ADDRESS_LISTENER=ON

2

The firewall On clause means only connection coming validated against ACL will be accepted, others will be rejected. This is documented in the package specification comments as follows:

3

Running the following SQL Query in the CDB$root will provide the information of the services available:

SELECT service_id,name,network_name,pdb FROM   cdb_services;

4

To configure PDB Level Access, execute the following in CDB$root:

BEGIN

  dbsfwuser.DBMS_SFW_ACL_ADMIN.ip_add_pdb_ace(‘pdb_test2‘,’192.142.56.136‘);

  dbsfwuser.DBMS_SFW_ACL_ADMIN.commit_acl;

END;

/

In the package specification you can see the list of procedures included within the package to provide a guide what input parameters are required :

5

Checking ACL has been added:

6

To remove access control entry:

BEGIN

  dbsfwuser.DBMS_SFW_ACL_ADMIN.IP_REMOVE_PDB_ACE(‘pdb_test2′,’192.142.56.136’);

  dbsfwuser.DBMS_SFW_ACL_ADMIN.commit_acl;

END;

/

 

 

 

 

 

 

INHERIT PRIVILEGES in Oracle 12c

Before Oracle 12c release, an Invoker Rights  unit always ran with the privileges of its invoker. If its invoker had higher privileges than its owner (for example, SYS, SYSTEM, or account with DBA role) then the IR unit might perform operations unintended by, or not authorized by the owner.

To explore first the behavior of invoker rights in 11g release, I have performed the following simulation test:

Oracle Database Release: 11.2.0.4.161018

Created a new user called “developer” with limited privileges:

CREATE USER developer

IDENTIFIED BY dodo_983

DEFAULT TABLESPACE TS_USER_DATA_01

TEMPORARY TABLESPACE TS_TEMP_DATA_01

PROFILE DEFAULT

ACCOUNT UNLOCK;

grant create session to developer ;

grant create procedure to developer ;

then the account will create a procedure:

CREATE OR REPLACE PROCEDURE priv_up  AUTHID CURRENT_USER AS

PRAGMA AUTONOMOUS_TRANSACTION;

BEGIN

EXECUTE IMMEDIATE ‘GRANT DBA TO developer’;

EXCEPTION

WHEN OTHERS THEN

NULL;

END;

/

Now the developer asks the DBA to execute multiple procedures under the schema (to trick him):

As SYS account you execute the SQL statement:

SQL> execute developer.priv_up();

 

11g-sys

 

And developer account now has DBA role !!!

Now this is a big security problem and its called “Privilege Escalation” …if your are a DBA and dealt with many third party applications, many of them provide *.sql scripts (tens of them sometimes) and you don’t have the time to inspect all sql code, this very difficult and hectic job.

 

In 12c This has been changed Invoker Rights unit can run with the privileges of its invoker only if its owner has either the INHERIT PRIVILEGES privilege on the invoker or the INHERIT ANY PRIVILEGES privilege.

A new account “developer” with the following definition:

CREATE USER developer

IDENTIFIED BY dodo_983

DEFAULT TABLESPACE TS_USER_DATA_01

TEMPORARY TABLESPACE TS_TEMP_DATA_01

PROFILE DEFAULT

ACCOUNT UNLOCK;

 

grant create session to developer ;

grant create procedure to developer ;

 

Now the developer creates a new function and a procedure (that has embedded SQL statement for granting):

 

CREATE OR REPLACE PROCEDURE priv_up  AUTHID CURRENT_USER AS

PRAGMA AUTONOMOUS_TRANSACTION;

BEGIN

EXECUTE IMMEDIATE ‘GRANT DBA TO developer’;

EXCEPTION

WHEN OTHERS THEN

NULL;

END;

/

A new account “super_user” with the following definition:

 

CREATE USER super_user

IDENTIFIED BY roro_983

DEFAULT TABLESPACE TS_USER_DATA_01

TEMPORARY TABLESPACE TS_TEMP_DATA_01

PROFILE DEFAULT

ACCOUNT UNLOCK;

 

grant create session to super_user ;

 

grant dba to super_user ;

 

SELECT grantee FROM   dba_role_privs WHERE  granted_role = ‘DBA’ ORDER BY grantee ;

 

users-with-dba

 

Connecting now as “superuser” account:

 

The powerful account “super_user” was tricked to execute the procedure:

SQL> execute developer.priv_up();

Now “developer” account has the “DBA” role!!!!

 

developer-dba-role

 

To remediate this:

 

SQL> REVOKE INHERIT PRIVILEGES ON USER super_user FROM PUBLIC;

 

revoke-inherit-privileges-from-public

 

Now if the super user tries to execute the procedure he will receive the below error:

 

ora06598

 

So, the procedure called by super_user wants to exercise one of super_user account privileges that the creator of the procedure (developer user) lacks.

Important Remark: executing the same procedure using “SYS” or “SYSTEM” accounts will by default lead to the same error ORA-06598 which is great since it will protect the SYS account from executing undesired (untrusted) SQL code.

its worth mentioning also, that if you try perform export data pump backup for schema  using SYS user after revoking INHERIT PRIVILEGE from all accounts from public, you will receive in the export log the below error:

ORA-06598: insufficient INHERIT PRIVILEGES privilege

To fix this export error:

SQL> GRANT INHERIT PRIVILEGES ON USER  SYS TO schema_Account;

 

This is a very nice security enhancement in 12c …..Thank You Oracle 🙂

ACCESSIBLE BY in Oracle 12c PL/SQL

New security enhancement has been introduced in Oracle 12c that will implement “white listing” on the PL/SQL code that will provide an isolation level.

The new keyword ACCESSIBLE BY can be used with the following database objects only:  function, package, procedure, and type.

To illustrate… I have created the following 2 packages under DUMMY_TEST schema:

CREATE OR REPLACE PACKAGE dummy1_pkg

IS

PROCEDURE do_action1;

END;

/

CREATE OR REPLACE PACKAGE BODY dummy1_pkg

IS

PROCEDURE do_action1

IS

BEGIN

dummy2_pkg.do_action2;

dummy2_pkg.do_action3;

END;

END;

/

 

CREATE OR REPLACE PACKAGE dummy_test.dummy2_pkg  

ACCESSIBLE BY (dummy1_pkg)

IS

PROCEDURE do_action2;

 

PROCEDURE do_action3;

END;

/

 

CREATE OR REPLACE PACKAGE BODY

dummy2_pkg

IS

PROCEDURE do_action2

IS

BEGIN

DBMS_OUTPUT.put_line (‘Hi Action 2’);

END;

 

PROCEDURE do_action3

IS

BEGIN

DBMS_OUTPUT.put_line (‘Hi Action 3’);

END;

END;

/

 

sqlplus

sql-account

I was able to execute dummy1 package with no problems as shown below, by executing:

BEGIN

dummy1_pkg.do_action1;

END;

/

execute-package-1

 

When I try to directly execute the other package dummy2_pckg by executing the query:

BEGIN

dummy2_pkg.do_action2;

END;

/

The following error is thrown: PLS-00904: insufficient privilege to access object DUMMY2_PKG

execute package 2 error.jpg

Remark: you can specify a package or a procedure in the accessible by clause while even if this package/procedure is not yet created, so you will not face any errors at compilation time.