|
|
|
|
| |
| The Internet Security Systems (ISS) X-Force has discovered several vulnerabilities in super-user owned executables that local users can use to gain root. Attackers may use these vulnerabilities to create, destroy, or modify any file on the system, including files owned by the super-user. This attack may be particularly useful to gain complete control of the database system, to manipulate Oracle database files, or to deny service. |
| |
Credit:
This vulnerability has been found by: Dan Ingevaldson of the ISS X-Force.
|
| |
Affected Versions:
ISS X-Force has determined that all current versions of Oracle 8 for Unix are vulnerable. These versions include: 8.03, 8.04, 8.05 and 8.15. Oracle 8 for Windows NT is not affected by these vulnerabilities.
Description:
Oracle has made a recent effort to secure setuid administrative tools shipped with Oracle 8. Certain utilities are still shipped with the setuid bit enabled. The super-user also owns these utilities. Despite Oracle's efforts, these vulnerabilities are still exploitable in the most current revisions of Oracle 8 for UNIX. The vulnerabilities described in this advisory are similar to those described in the May 8th ISS X-Force
Advisory titled, "Multiple File system Vulnerabilities in Oracle 8". These vulnerabilities are also a result of implicit trust of Oracle system environment variables, as well as insecure file creation and manipulation. The combined effect of these vulnerabilities may allow local attackers to create, append to, or overwrite any file on the file-system as well as privileged oracle files.
Temporary files that follow symbolic links are a common source of vulnerabilities in setuid executables. Administrators should remove or restrict access to setuid executables if possible.
Developers of setuid programs need to take special precautions to prevent the introduction of vulnerabilities of this nature. It is recommended that all Unix developers become familiar with Matt Bishop's secure programming guide, available at http://olympus.cs.ucdavis.edu/~bishop/secprog.html
Fix Information:
Oracle has provided a patch for the vulnerabilities described in this advisory. This patch is available to the public on technet.oracle.com. The direct URL is http://technet.oracle.com/misc/agent/section.htm.
Oracle has provided the following information to answer any questions concerning these vulnerabilities. The FAQ is available in HTML format at http://technet.oracle.com/misc/agent/faq.htm.
1. Do I need to upgrade my databases to 8.0.5 or 8.0.6 in order to pick up this fix?
No! The Agent may be upgraded on its own, without affecting the version of the databases it manages. To do this, install the Agent and the appropriate patch in a separate Oracle Home. This Agent will be able to manage all targets on its node, irrespective of their versions.
2. What can I do until the fix is available on my platform?
While waiting for the fix to be available on your platform, you may use the following workaround: Create a Unix user with normal permissions under which the Agent runs Enterprise Manager jobs.
Note: This means all jobs submitted through the Enterprise Manager Console will now run as the 'normal user' instead of the user specified as preferred credentials within the Console. Additionally the 'normal user' will only have access to the \ORACLE_HOME\Agent directory, unless otherwise specified by the system administrator. Finally, the Agent will only start as the 'normal user.'
Steps to apply the workaround:
On the system on which the Agent resides, choose or create a UNIX user with normal permissions to the system. This user must not be: (A) The user who installed the Oracle RDBMS Server and other Oracle products on the system OR (B) a user with root privileges. The user must belong to a normal group and not "dba".
For example:
1. Create a user "agent" belonging to group "agentgrp".
2. Install an Agent in a new Oracle Home as user "agent". Note: do not run the root.sh script under this Oracle Home as part of this installation process.
3. Shutdown the old Agent.
4. Copy files from the Oracle Home of the old Agent to the Oracle Home of the newly installed Agent as follows:
cp $ORACLE_HOME(old)/network/agent/* $ORACLE_HOME(new)/network/agent
Important: Make sure that the user "agent" owns all files under the $ORACLE_HOME(new)/network/agent directory.
5. Using a terminal window that has the environment of user "agent", start the Agent with:
lsnrctl dbsnmp_start
For further security, job system access can be prevented if you are using Enterprise Manager version 2.0.
To do so, log into the Enterprise Manager Console as a Super Administrator. Using the System -> Manage Administrators option, edit the General Preferences, deactivating 'Access to Job System' for each Administrator you wish to prevent from using the job system.
If you are not comfortable with this workaround, suspend the use of the Agent until the fix is available on your platform.
It is recommended that all administrators also complete a proactive survey of their Oracle installations to determine which machines require the Intelligent Agent.
|
|
|
|
|
|
|
|
|
|
