Database Reference
In-Depth Information
Well, in this example we have used RC4 with a 40-bit key. The performance hit of this algorithm and key
size is negligible, but of course the protection from decryption is lower than higher key sizes and algorithms.
If your environment prioritizes security over performance then it is worth considering stronger encryption such
as the following:
sqlnet.encryption_server=accepted
sqlnet.encryption_client=requested
sqlnet.encryption_types_server=(rc4_256)
sqlnet.encryption_types_client=(rc4_256)
The main thing is not to use plaintext, and there is now no excuse for doing so, as the encryption is free. You can
confirm as much by looking at the following documentation from Oracle:
Specifically, look for the text in the document that reads:
“Network encryption (native network encryption and
SSL/TLS) and strong authentication services (Kerberos, PKI, and RADIUS) are no longer part of Oracle Advanced
Security and are available in all licensed editions of all supported releases of the Oracle database.”
Network encryption has already been made free of charge for listener-to-server communication in order to
mitigate the problem of registering additional Oracle proxy instances to a listener, which is an issue called
Tnspoison
(
http://www.joxeankoret.com/download/tnspoison.pdf
and Doc ID 1340831.1). In my experience, setting SSL
and wallets is a lot more labor-intensive than the above native network encryption setting, so for client-to-server it is
quicker and easier to use native encryption. However, if you would like to both encrypt the session and identify the
client to the server through the use of a signed certificate, then it is well worth using SSL/TLS wallet from client to
server in the same way as the above Doc ID. This may result in maintenance overhead over time as well as cost for
signed certificates. The cost can be avoided by setting up an internal self-signed certification authority within your
organization. The cost-benefit of certificates is not as high as the simple encryption shown above, which should be
regarded as a “must.”
Privileged Access Control's Achilles' Heel
Let's remind ourselves of the privilege escalation issue as regards 12c. Basically it is a lot more difficult to enact
security controls on highly privileged accounts. “Cat herding” is not easy, but it's even harder when the cats are lions!
The common solution is to grant the least privilege by subdividing high privileges into smaller privileges that
are more controllable and delegating them through the use of roles, but the problem is that Oracle's open design and
complex nature make it possible for medium-level SYSTEM privileges to be used to escalate back up to SYS. SYS can
modify its audit trail, change other users' passwords, and read all the data. This problem is not solved on a default
install of 12c, as the following example shows.
On 12.1.0.1.0 the SYSTEM database account allows the DBA role to be accessed from stored procedures in
its schema via definer's rights by whomever the invoker of a procedure may be. So a medium-privileged user can
escalate from being able to
CREATE ANY PROCEDURE
to using the SYSTEM account's DBA role. Roles granted to the
schema owner are meant to be turned off for access through definer's rights procedures, but for SYSTEM they are not,
and because SYSTEM is outside the protection of
O7_DICTIONARY_ACCESSIBILITY
parameter, the following privilege
escalation becomes possible. This escalation is from
CREATE ANY PROCEDURE
to
DBA
and has been published on
ora-600.pl
for 11g, but at the time of writing it had not been published that 12c is susceptible to a similar issue, as
demonstrated here. I have reported this fact to the Oracle Security Alert Team:
C:\Windows\System32>sqlplus sys/o@192.168.56.101/orcl as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on Thu Nov 28 19:35:41 2013
Copyright (c) 1982, 2013, Oracle. All rights reserved.
