Oracle Removing Security Permissions Oracle Security Tips by Burleson Consulting

This is an excerpt from the bestselling book "Oracle Privacy Security Auditing", a complete Oracle security reference with working Oracle security scripts.
 

---

Removing Permissions from Oracle Executable

In most Oracle installations, the default installation leaves the execute permissions for the oracle executable to x, i.e. executable by others. However, this creates a severe vulnerability. This allows anyone, including those not even connected with the Oracle database, such as GUEST or NOBODY, to run the program and create log files or at least corrupt some of them. Simply removing the Oracle executable permissions from others as follows can prevent this.

chmod o-x $ORACLE_HOME/bin/oracle

This will stop anyone other than the DBA group from executing the Oracle executable directly.

Resetting these permissions will result in any non-DBA user not being able to execute Oracle directly, and therefore being unable to connect to Oracle using the Bequeath adapter. This is definitely a desirable situation. Everyone should preferably connect through the listener, as you will see in Chapter 7, under Network Security. Removing this will force the users to connect using IPC, or even TCP/IP, where a detached process is created for each client process.

Here, the UNIX user NOBODY has tried to login to Oracle when the execute permissions for others have been removed from the Oracle executable.

mighty.proligence.com:/usr/users/nobody> sqlplus

SQL*Plus: Release 8.1.7.0.0 - Production on Thu Jul 10 15:20:21 2003

(c) Copyright 2000 Oracle Corporation.  All rights reserved.

Enter user-name: scott/tiger
ERROR:
ORA-12546: TNS:permission denied

Note the error: “ORA-12546: TNS:permission denied,” meaning the execute on the Oracle executable failed. However, the connection is attempted now using a connect string, i.e. forcing it to go through the regular IPC or TCP/IP process.

Enter user-name: scott/tiger@claimdb
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - Production
With the Partitioning option
JServer Release 8.1.7.4.0 - Production

SQL>

The connection was successful.

* Remove the execute permissions on Oracle executables from others as a precaution to prevent malicious use.

Filesystem Permissions

Oracle uses several filesystems to place a variety of files. We will assume here that the Oracle software owner is oracle and the primary group is oinstall, with other memberships in the group dba.

The directory where the Oracle software files are stored is called Oracle Home, identified as an environmental variable in UNIX labeled ORACLE_HOME.

Oracle itself recommends files be placed in a format called Oracle Flexible Architecture (OFA). This increases convenience, but at the cost of increased security risk. For that reason, we don't recommend following the OFA for your file placements. Rather we recommend the structure outlined in table 4.2

FILESYSTEM	DESCRIPTION
1	Oracle Home, where the Oracle software code is stored. It also houses the directories used for background dump destination and core dump destination files. Should be owned by Oracle with permissions rwx for owner, r-x for group and --- (i.e. no permission) for others.
2	Trace Files are generated in the directory specified by the parameter user_dump_dest. This should be placed in a separate directory because sometimes the users might be given permission to read files from here. SQL Trace files are generated here, and any event setting causes files to be written here too. Therefore, this directory should be separate. It should be owned by Oracle, with rwx for owner, r-x for group and others. Remember to update the initialization file of the instance to point the parameter user_dump_dest to this directory.
3	The user interaction directory is placed here. The files created using the package utl_file are generated in this directory. Since users will frequently read and write files in this directory, this should be separated. The directory should be owned by Oracle with permissions set for read, write and execute for everyone. Please note then in Oracle 9i, the utl_file package does not need this parameter to be set in init.ora to manipulate a file. The DIRECTORY object can be dynamically created and used as the directory. Therefore, the days of this filesystem could be numbered.
4	The rest of the files contain the Oracle required files such as controlfiles, datafiles, redolog files, archived log files, etc. could be placed in a single filesystem or more. The permissions should be similar to the Oracle Home directory.

Table 4.2 Filesystems and their recommended permissions

We can't stress enough how important it is to set the permissions for Oracle database data files to 640 permission levels, i.e. no read access to others. A hacker could open these files using a hex editor, and try to read the files. It's difficult, but possible. In addition, these files could be copied over to a different server and be replicated.

* Tip:  Make sure the utl_file_dir  parameter in the database is not pointing to "*", i.e. to read and write anywhere Oracle has access to. Change permissions as described in the above table.

Other Settings Related to Filesystems

One of the most potentially damaging commands is the ability to create directories with the CREATE DIRECTORY command. A user can create a directory on any filesystem where Oracle has permission to create files. A malicious user can create a directory on some sensitive filesystem and then read or corrupt data on that using BFILE type files. This vulnerability does not seem to be quite understood, otherwise, it would be shut down immediately, and doing so is very easy. All you have to do is to remove the system privilege CREATE DIRECTORY from users.

* No regular user should have the CREATE DIRECTORY system privilege.

The other problem is setting the parameter _trace_files_public in init.ora file to TRUE. The parameter is necessary, as some developers may want to create valid trace files such as sql_trace, or set events and analyze them in tools such as TKPROF. Ordinarily, these trace files are not readable by the public, therefore, the developers can't get them directly from here. Setting the init.ora parameter to TRUE will make them readable by all.

However, setting this to TRUE has serious consequences. The trace files are not only created from user actions such as setting sql_trace, but also by the database itself, triggered by setting events, errors or informational messages from other Oracle processes, such as fine grained access control (FGAC), etc.

This information is sensitive and should not be made available to anyone. For instance, a system dump may contain passwords changed in the last few minutes and that is exactly what the malicious user is after. The trace files are not public to prevent exactly these potential threats, and they should never be public. This is a reason why the parameter is an underscore, i.e. hidden one.

* Do not set the parameter _trace_files_public to TRUE in init.ora.

Sometimes hackers employ another tactic to get information. The trace file directories are mounted on another machine, or are shared by another host. This allows the hacker to gain access by simply checking the directory without even logging in to the server.

* Never mount, share, or export the trace file directories.

utl_file_dir Wildcarding

The Oracle built-in package utl_file needs a special parameter named utl_file_dir that points to a directory on the server, not the client, where the files can be manipulated via the package. This directory should be such that the OS user ORACLE would be able to manipulate (read and write) files there. Instead of specifying a directory, a wild card character "*" can be entered that will allow manipulation of files in any directory. The wild card parameter is specified in the initialization file as

utl_file_dir = *

DBAs sometimes, mainly due to a lack of clear requirements, set this to * so that the developers can easily read and write files anywhere they want. Since changing this parameter needs a database recycle, the normal temptation is to set this wildcard. Nothing can potentially cause as much damage as this setting. Remember, the parameter signifies the directory that the Oracle software owner user can manipulate. This will allow a user to open up any file readable and writable by Oracle – including the datafiles! Even legitimate users without any malicious intent could inadvertently damage the files this way.

Therefore, never set the parameter to the lazy setting of *; always use a specific directory name, and that directory should not be one where the Oracle database sensitive files are present.

* Never set the initialization parameter utl_file_dir to "*".

 

This is an excerpt from the book "Oracle Privacy Security Auditing". You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle security and auditing scripts.