Call: +44 (0)1904 557620 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Creating a DIRECTORY - Forensics Example in 23c"] [Next entry: "SQL Firewall Oracle 23c - Part 1"]

Oracle 23c Deprecated Parameters that could Affect Data Security

Let us have a brief look at Oracle 23c database parameters marked as deprecated in the database that can be in some respect related to security. Here are the parameters are marked as deprecated in 23c:

SQL> col name for a40
SQL> col value for a100
SQL> set lines 220
SQL> select name,value from v$parameter where isdeprecated='TRUE';

---------------------------------------- ----------------------------------------------------------------------------------------------------
pre_page_sga TRUE
resource_manager_cpu_allocation 0
db_block_buffers 0
fast_start_io_target 0
serial_reuse disable
cursor_space_for_time FALSE
plsql_v2_compatibility FALSE
plsql_debug FALSE
background_dump_dest /opt/oracle/product/23c/dbhomeFree/rdbms/log
user_dump_dest /opt/oracle/product/23c/dbhomeFree/rdbms/log
sql_trace FALSE
parallel_adaptive_multi_user FALSE

20 rows selected.


There are a small number of interest to securing the database. Lets have a look at some:

  • rdbms_server_dn: This is used to get the distinguished name of the server (DN) from the database for use in enterprise roles when they are in an enterprise directory server

  • plsql_v2_compatibility :This is deprecated for a long time and this allows if set to TRUE old behaviour to be used in PL/SQL. Use of this could occur if you use a very old third party PL/SQL based application. If the application is under your control, change it!

  • plsql_debug :This parameter is retained for backwards compatibility but has been deprecated for some time as above. If this were set to TRUE then all PL/SQL would be compiled with debug so could be used to intercept a PL/SQL procedure/package at run time and more easily steal data

  • background_dump_dest :Also deprecated for a long time since 12.1 but retained. It is ignored if set if the diagnostic_dest is used. If used this is the location of the alert log and also background process trace files. We should be aware that these files can contain structural details of the database and also in some cases data (in SQL or in memory dumps). We should control the locations of where the alert log is written and also these trace files BUT importantly make sure that they are managed; archived, purged and be aware that that can contain useful information to a hacker

  • user_dump_dest :This is also deprecated a long time and also affected by the diagnostic_dest. This parameter controls where user created trace is written and for the same reasons as above these trace files must be managed, archived, purged as they can contain data that is not protected in the database with database security

  • sql_trace :This parameter is dangerous as it could be used to kill the database by enabling it at the database level. If this were the case and the file systems are not adequate then the database could be hung. Also remember that setting sql_trace effectively gives only Oracle v6 trace as there are no binds and waits. Oracle suggest that you use DBMS_MONITOR or DBMS_SESSION instead and trace should be targeted not system wide

A lot of these parameters are deprecated for some time and not newly deprecated in 23c and should not be used for reasons above. Check in your database that these are not set and be aware that security is everywhere in an Oracle database.

#23c #dbsec #oracleace #oracle #security #parameters