Database Reference
In-Depth Information
The parameter benefits from being kept simple. One of the security design flaws of the Oracle database
engine is that the engine as a whole is too complex. Look at the user profiles, for instance. Many DBAs do not fully
understand how
password_reuse_max
and
*time
work together, because those parameters are too complex in their
implementation. Installation paths and Unix configurations such as
dba/oinstall
groups are too configurable by
each individual DBA, thus making their installation potentially non-standard. An organization should not be in a
position in which one administrator can customize a system so that another administrator cannot understand it.
When that understanding is lost, then security issues tend to creep in. So
_sys_logon_delay
is just a simple
one-second delay for SYS turned on by default.
■
all password file users such as sYs, including the new
SYSKM/DG/BACKUP
user, are under the control of
_sys_logon_delay
by default; i.e., not just sYs—, but all pwfile users.
Note
In my opinion, the
_sys_login_delay
parameter is a success for the Oracle security team and their partners,
but the general picture of the administrative high privilege being less controlled and secured than the low-privilege
accounts is still true. SYS is still immune to profiles and the password verification function, so there is still work to do.
Controlling admininstration privileges like SYS is a specialized area of security within Identity Management named
“Privileged Access Control” and will be the subject of Part IV.
Default Account Attacks
After SYS come the default accounts, which may be lower-privileged but, because they are very probably present,
still represent a risk of external penetration. This is why in 12c all the default accounts other than SYSTEM and SYS
are locked and expired. Thus, the threat is mainly from the default accounts that a DBA opens after the initial install.
Some default accounts will almost certainly be open, e.g.,
DBSNMP
and the commonly added
PERFSTAT/PERFSTAT
,
and the default accounts do tend to get resurrected, so it is important to have regular checks for default username/
passwords. On the whole, the problem of default accounts has been reduced in 12c. However, DBSNMP access
through Cloud Control does still represent a risk that needs managing, as we will discuss in the “Cloud Control”
section in Part V.
The removal of select ability on
SYS.USER$
from
SELECT ANY DICTIONARY
system privilege is another indicator
that Oracle is getting on top of their accounts. The ongoing problem is now third-party applications that add on to
Oracle after installation but still have default passwords, e.g., TOAD/TOAD.
Privilege Escalation through Public Privileges
A generic design flaw in Oracle DB that has not been solved in 12c is the problem of privilege escalation. A low-privileged
user within the database can commonly find a way to escalate their privilege to SYSDBA. For some environments this
is not so critical. It is understandable that a back-end DB that has one DBA in a DMZ, with a front-end application
that manages its own users, has less need to remove privilege escalation from the DB, especially if the front-end
application is securely coded. The focus in that environment will be on performance to keep the front-end application
running smoothly. However, a warehouse environment where there is direct access to the DB, or in the common
scenario of an application that suffers from SQL injection, privilege escalation becomes a greater issue. For internal
use over a network topology using open routing, the front-end application may be bypassable by clients using
SQL*PLUS, which is when privilege escalation becomes even more relevant.
