Database Reference
In-Depth Information
OS Access from the DB
One of the best features of Oracle is that it integrates with *nix tightly and enables data to be dumped to the OS and
read back in again. The problem is that virtually all database security is dependent on the DB session not being able
to run commands from the OS. This is concerning because when a DB session extrudes from the Oracle database to
the OS, it is running as the '
oracle
' process owner of the DB itself. Therefore, if that process comes back into the DB
via SQL*PLUS, it is elevated to SYS. The ability to run commands on the OS from the DB effectively represents having
SYS privileges. This design issue is not easy to fix. Oracle is designed to work from Unix, so this issue of OS access will
likely be a source of potential risk for many years to come. However, there are ways to safeguard against the problem,
and I'll talk about some of those in Chapter 11.
Privilege Escalation to SYSDBA
Even in 12c there are new privilege escalations, as will be shown in Chapter 10. Over complexity of privileges and lack
of visibility on how those privileges are nested within roles, coupled with the lack of a DENY statement, lead towards
over-aggregation of privileges. Additionally, the working functionality of a system privilege can be used to gain a
higher system privilege. This is true with the ADVISOR privilege, which can escalate to SYSDBA on 12c without the
need for directory privileges.
Privilege Extension
Users and privileges that cannot be individualized and have segregation-of-duty issues, like
'
oracle' Unix or SYSDBA,
often rely on time-limiting a session to a specific human user. That time window of SYS usage is associated with that
specific DBA, the one doing the work. This is how access to high privilege is managed in secure environments. After
the time window has elapsed, the session is terminated. OPAM, BeyondTrust, Xceedium, and CyberArk EPV enact this
type of system.
The problem is that privileges such as SYS intrinsically have the ability to extend their time window beyond the
authorized time. Give a skilled user SYS for five minutes, and they are able to persist their access forever by installing
backdoor access, which effectively bypasses the time control. This sort of attack is almost impossible to prevent, but
new research is moving toward reliable identification and alert. Break-glass privileged access control enables an
organization to take control of the highest Oracle privilege, to the point where consolidation can take place at lower
risk. This will be the subject of Part IV of this topic and is an area of active research. An example method of privilege
extension is using the oradebug tool. That tool allows a SYSDBA user to write directly to memory, thus overwriting the
addresses that control auditing and authentication. Oradebug is still accessible to the SYSDBA on 12c. Its continued
ability to write directly to memory should be considered a security flaw in 12c, of which there are unfortunately still a
few, as we shall see in the next chapter.
