Problem Description:
~~~~~~~~~~~~~~~~~~~~
Database link passwords are stored as plaintext. A database link is a mechanism
used to provide a method of transparently accessing one server from another.
When creating a database link, a user name and password of the account on the remote
server can be specified. Creating the database link without credentials works
only if the user exists on both databases and has the same password.
Once this is done, all queries using the link have the privilege of the
indicated account on the remote server. By omitting an account and password when
creating a database link, the account and password of the user connecting
through the link is used. Indicating the username and password of an account to
use for all connections through a link can lead to passwords being exposed.
Database link passwords until recently (version 10gR1) were stored unencrypted in
the database. Users with SELECT privilege on the SYS.LINK$ table could view the
passwords in plain text. Setting up links to authenticate as the current user
prevents unencrypted passwords from being exposed, prevents linked servers from
being compromised, and provides increased accountability.
Oracle accounts were found with permission to view the table SYS.LINK$. Access
to view the table SYS.LINK$ should be restricted because database link passwords
are stored unencrypted in this table.
Possible Symptoms:
~~~~~~~~~~~~~~~~~~
If you have SELECT ANY TABLE privilege on a database, you can see the password
of the user that can belong to a remote or local database(s) in the SYS.LINK$ table
and using this password, you can connect these remote or local databases at will.
We rely on sys to protect link$. If customers don’t trust a DBA, there are many
things the DBA can do that make any encryption attempt useless.
Important change in the SELECT ANY DICTIONARY system privilege
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In Oracle release 10gR1, the access to SYS.LINK$ was removed from the
SELECT ANY DICTIONARY system privilege (hence the ORA-1031 error), while this
still doesn’t solve the general problem: tools such as Oracle Enterprise Manager
that depend on SELECT ANY DICTIONARY to be available can be deployed without
access to SYS.LINK$.
Workarounds:
~~~~~~~~~~~~
There are no workarounds to protect against this potential vulnerability but
it is possible to use this:
-> Drop the database link and create a link without specifying an account and
passwords.
To drop a database link, execute the command:
SQL> drop database link ;
To re-create a link without hard coding the password, execute the command:
SQL> create database link using
-> To revoke permissions from the account or role, execute the following
command:
SQL> revoke select on SYS.LINK$ from
Patches:
~~~~~~~~
Currently there is not a patched Installer available to deal with this problem.
One of the workarounds listed above must be used.
It is no more the case under version 10g Release 2 (10.2.0.x), the LINK$ table
now contains a new column PASSWORDX that contains the encrypted database link
password. Details of the encryption scheme will not be disclosed for obvious reasons.