I am trying to confirm/refute whether item 1 "DBLink password can be easily decrypted" from White Paper "Database Link Security, Paul M. Wright, 19/11/2012" is an actual, recognized vulnerability. The White Paper was presented at the December 2012 UKOUG, but my tests with it failed. Clearly the actual, full exploit was not divulged and my knowledge of the package used is too rudimentary to troubleshoot my errors.
Is it recognized as an actual vulnerability by Oracle?
If so, is there a CVE and what is the CVE number?
Has it been managed by PSU or CPU?
If so, which release?
If not, when can we expect a fix?
Thank you for your help,
Edited by: Laura Sallwasser on Apr 5, 2013 10:13 AM
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?
which the documentation refers to as a "connected user database link". This is slightly different than the CURRENT_USER option.