SYS.LINK$ Shows all Database Link Passwords unencrypted

From Metalink Note 202987.1:

Problem Description:
Database link passwords are stored as plain text.
A database link is a mechanism used toprovide 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 [link name];

To re-create a link without hard coding the password, execute the command:
SQL> create database link using [connection string];

To revoke permissions from the account or role, execute the following command:
SQL> revoke select on SYS.LINK$ from [account or role] ;

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.