Value FROM v$option where parameter = ‘Unified Auditing’

Hi all,
So, just a quick post to clarify once it cost me a few mins to explain this to a client and, indeed, Oracle could have made it easier.

So, facing the info below, doesn’t mean that you don’t have Unified Auditing enabled:

SELECT value FROM v$option WHERE parameter = 'Unified Auditing';
VALUE
-----------------
FALSE

It does mean you just don’t have PURE Unified auditing, but a MIXED configuration, where old fashioned Auditing is also accepted.

See, this way, the MIXED Auditing is by default it is enabled in 12c. The idea is that you use apart from traditional auditing all the features of unified auditing. Once we are comfortable with the unified concept, we can migrate exiting audit setup to unified policy , we can enable pure auditing. This serves as a good mediator for an easy and hassle free switch to the preferred Unified auditing.

HOWEVER, let’s agree that Oracle could have made the value column a little bit m ore meaningful, if this was the case. The actual values actually mean:

FALSE – > MIXED AUDTING
TRUE –> PURE AUDITING

OK, but what if I want to enable ONLY the PURE Auditing, disabling the ‘Classic’ Auditing and changing this value on v$option to TRUE? Well, then you need to relink library for your instance. Note, for RAC linking need to be done all the nodes.

Steps to Change to PURE Unified Auditing Only:

SELECT value FROM v$option WHERE parameter = 'Unified Auditing';
VALUE
-----------------
FALSE

sqlplus / as sysdba <<
shutdown immediate;
exit;

cd $ORACLE_HOME/rdbms/lib
 
make -f ins_rdbms.mk unaiaud_on ioracle
 
sqlplus / as sysdba<<
startup
 
SELECT value FROM v$option WHERE parameter = 'Unified Auditing';
VALUE
-----------------
TRUE

Reference: https://docs.oracle.com/database/121/DBSEG/auditing.htm#DBSEG824

Hope it helps, cheers!

Oracle Security: Immediate Protection for JVM Exploits (CVE-2018-3110)

Hello all!

Now that CVE-2018-3110 is a hot topic, I think this is a pretty interesting topic to go on.

So, we all know this is consistently one of the components with more CVEs for Oracle Databases. Basically because you can create Java objects in the database (which I think is an abomination :D) and run this code there, usually doing some tricks to escalate privileges to DBA, to PDB, to CDB, to host and other CDBs…

The problem is that (before 18c) OJVM PSU Patches are not RAC Rolling installable. Which means will need a maintenance window to apply fixes for this component. Quite bad, hãn… And if you discover a vulnerability and the PSU window is only in a month or so?

Well, we have a solution 🙂
It is well described in MOS Oracle Recommended Patches — “Oracle JavaVM Component Database PSU and Update” (OJVM PSU and OJVM Update) Patches (Doc ID 1929745.1), under the name “Mitigation Patch”.

It basically consists in install a patch Patch 19721304: SCRIPT TO LOCK DOWN JAVA DEVELOPMENT, which is a Rolling Patch, which allows you to disable any new Java object to be created. This is, so, assuming exploits can be done by creating new java objects on DB (as most of Java CVEs). Also, this patch don’t have any version requirement (after 9i).

Having the patch, however, doesn’t mean you are automatically protected against any vulnerability, but means you can protect yourself temporary by disabling new java objects creation with “exec dbms_java_dev.disable;” anytime.

The Mitigation Patch does not remove Java objects or block any java execution, it only disable the creation of new Java objects, so if the exploit is already planted, it’s not a viable solution. The mitigation patch can be used in any scenario where the PSU or proper JVM fixes cannot be applied at the moment but it’s wanted to prevent against JVM vulnerabilities.

Now, before downloading the patch, first check if it’s not already installed to your home, as it’s part of some Boundle Patches, like “Database Bundle Patch : 12.1.0.2.180417 (27338029)“.

Important Note: The intent is to be like a “workaround” while the PSU is planned. This was not built to be definitive solution. The idea is to just disable new Java objects to be created until the fix is applied on the proper planned maintenance window.

Hope it helps!

Oracle Security: Users with Default Passwords

Hi all!
Did you know since Oracle Database 11g we have a way to quickly identify users with default passwords?
It’s implemented in a really simple way, with a single data dictionary view: DBA_USERS_WITH_DEFPWD

You can identify these users with the query:

select * from dba_users_with_defpwd

Example of output:

USERNAME
------------------------------
DIP
MDSYS
WK_TEST
CTXSYS
OLAPSYS
OUTLN
EXFSYS
SCOTT
MDDATA
ORDPLUGINS
ORDSYS
XDB
LBACSYS
SI_INFORMTN_SCHEMA
WMSYS

You can see SCOTT listed above, because his password is TIGER, the default one. Change it with:

SQL> alter user scott identified by tiger1;

User altered.

Now if you check the view:

SQL> select * from dba_users_with_defpwd;
USERNAME
------------------------------
DIP
MDSYS
WK_TEST
CTXSYS
OLAPSYS
OUTLN
EXFSYS
MDDATA
ORDPLUGINS
ORDSYS
XDB
LBACSYS
SI_INFORMTN_SCHEMA
WMSYS

You don’t see SCOTT on the list anymore. It’s that simple!

Hope it helps to make you database more secure.
Cheers!

12c New Feature: Unused Privileges

Did you know 12c now has a mechanism to examine which privileges are actually being used by an user, module or for the database as a whole, as opposed to merely the privileges granted?
This is a great security improvement in order give users the privileges that they need precisely without granting too much.

Here’s how is works?

1. First you have to set up a capture process using the new package DBMS_PRIVILEGE_CAPTURE.

# Example:

BEGIN 
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( 
        name         => 'all_priv_analysis_pol', 
        description  => 'database-wide policy to analyze all privileges', 
        type         => DBMS_PRIVILEGE_CAPTURE.G_DATABASE); 
END;
/

This starts the capture process database wide. Let it run for a bit.

2. Now you can either generate a report:

# Example

BEGIN 
DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT( 
        name         => 'all_priv_analysis_pol'); 
END;
/

Or examine the new views:

DBA_USED_PRIVS 
DBA_UNUSED_PRIVS 
DBA_USED_OBJPRIVS 
DBA_UNUSED_OBJPRIVS

3. To turn off you proceed with the following:

BEGIN 
DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE( 
        name         => 'all_priv_analysis_pol'); 
END;
/

So now you ensure that you use the best practice of least privilege for users.

Cheers!

Vulnerability: Decrypting Oracle DBlink password (<11.2.0.2)

Hi all,
It’s not a new vulnerability, but a good thing to have personal note about it. Besides the security problem, it can save you from situations you need but don’t have the database link password.
It works only if the database link was created pre-11.2.0.2.

The vulnerability only is exposed if user has one of the follow privileges:
SYS
SYSDBA
DBA
SYS WITHOUT SYSDBA
SYSASM
EXP_FULL_DATABASE
DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE

combo_lock_page.jpg

Starting with 11.2.0.2, Oracle changed the hashes format for database link passwords, solving this vulnerability. But it only apply to dblinks created in this version or higher.
If you have dblink created when database was on 11.2.0.1, for example, and upgrade the database for 11.2.0.4, the problem remains until you recreate the database link.

So, if you are upgrading database from 11.2.0.1 or lower to 11.2.0.2 or higher, remember to reacreate database links!

The vulnerability was exposed in 2012 by Paul Wright. Here is his PoC.
And there is his post.

To make it different, below I made the same test (using a PLSQL block, to make it prettier) with an upgraded database, from 11.2.0.1 to 11.2.0.4:

testdb11204> select passwordx from sys.link$ where name='MY_DBLINK';

PASSWORDX
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0540C5B8090D021649C5C614E8E0C242AF33F71C08C535900C
1 row selected.
testdb11204> set serveroutput on
testdb11204> declare
2   db_link_password varchar2(100);
3  begin
4   db_link_password := '0540C5B8090D021649C5C614E8E0C242AF33F71C08C535900C';
5   dbms_output.put_line ('Password: ' || utl_raw.cast_to_varchar2 ( dbms_crypto.decrypt ( substr (db_link_password, 19) , dbms_crypto.DES_CBC_PKCS5 , substr (db_link_password, 3, 16) ) ) );
6  end;
7  /
Password: P4SSW0RD

Note that the simple upgrade does not solve the question. Is needed to recreate database link.

Matheus.