This content has been marked as final. Show 4 replies
The permissions you have affect whether you can access sys.link$ or not. When attempting this as my personal account (I do not have any of the roles listed in the white paper) I received ORA-01031: insufficient privileges.
When connected as SYS I was able to reproduce the example in the white paper by copying and pasting. I would say the paper fully discloses the exploit.
I would not necessarily consider this a vulnerability, but yet another reason to protect the highly-privileged users and roles in your system. If a user cannot see SYS.LINK$ they cannot get to the encrypted password to decrypt it.
Personally I prefer not to include passwords in database links, but define them without a password whenever possible, then anyone using the link must have the same password on the local and remote databases, and no password is stored in sys.link$. This arrangement is not always feasible.
Edited by: Brian Bontrager on Apr 5, 2013 4:08 PM
For others who may see this thread, I found the referenced paper here: http://www.oracleforensics.com/wordpress/wp-content/uploads/2012/11/database_link_security.pdf
Thank you for your reply. Are you referring to "connect to current_user" when you note "I prefer not to include passwords in database links, but define them without a password"?
If not, is there another way to define a database link without a password, or so that the password is not in sys.link$.passwordx?
I was referring to
which the documentation refers to as a "connected user database link". This is slightly different than the CURRENT_USER option.
create database link orcl2_link using 'ORCL2';
Thanks again. I see your point; this type is not always feasible.