Pete Finnigan's Oracle Security Weblog

I just found the first part of a series of papers written by Arup Nanda - It is entitled http://www.dbazine.com/nanda9.shtml - (broken link) Oracle Security and Auditing, Part 1: Securing Listener through a Password and as its name suggests its about protecting the listener with a password.

Whilst this is an admirable thing to do the short article doesn't go far enough. The paper gives a thorough description of both methods of using passwords for the listener, the change_password command where the password is set dynamically and also the method by which the password is added to the configuration file listener.ora. The latter method of adding a password in clear text should not be used. This has a number of problems. The first is that the password is in clear text and because of this it can be read by anyone with permissions on the file. The paper does not discuss this fact or the need for file level security. Also this method is weaker in some versions of Oracle as it can be abused and connecting to the listener is still possible without the password. The key is to not use this method but if it is used then the configuration file must be protected at the operating system level. This is also the case with the change_password method as the hash should not be divulged either.

If the hash value is known it can be installed off line on another listener and be brute forced. This brings me to another issue with the listener which was not mentioned. The fact that the listener has no password management features, ageing, locking of the account etc.

I covered in a similar issue in my blog yesterday about listener passwords and the ADMIN_RESTRICTIONS_{listener_name} parameter. This parameter can also be used effectively to prevent changes to the listener configuration through the listener control utility. This is also a worthwhile addition to the things mentioned in Arups paper.

Arup also makes a statement in his article:

"This will make the work of the hacker impossible unless the password is known."

This is not true, the hacker can simply brute force the password if its not known because there are no protections built into the listener to prevent multiple failed login attempts. Also if it’s possible to get the listener password hash then it’s possible to brute force it off line.

This paper is the start of what looks likely to be a good series from Arup who is a good author. This is a good paper that covers its subject well but as I said I think it could have gone further and covered file permissions, password attacks and also restricting dynamic configuration of the listener.