RE: Listener Vulnerabilities - how to address them

From: Johnson, William L (TEIS) <>
Date: Wed, 9 Apr 2008 12:52:55 -0400
Message-ID: <>

If I am not mistaken, you can still password protect your listener and then write a wrapper script around your listener commands that will permit you to stop and start the listener through batch processes. As long as you take the time to ensure the listener.ora file is only readable by the Oracle account - and no other accounts on the machine, you should be good to go.

You can set the password for a listener command by picking up the password out of the listener.ora file.

-----Original Message-----
[] On Behalf Of Tony Sequeira Sent: Wednesday, April 09, 2008 12:20 PM To: Oracle List
Subject: Listener Vulnerabilities - how to address them

Hi All,

Most of you are probably aware of the following document, or similar. _Listener_TNS_Security.pdf

We support roughly 100 Oracle databases ranging from 8i to 10g, running on Windows and Unix (Solaris), mostly 9i.

The above documentation has been brought to our attention by one of our users. The questions being asked are:

Are we vulnerable?
If so, how do you propose to address that?

I'm still doing some investigation, thought I would see if someone here has:

  1. Come across this problem and sorted it
  2. Known about this problem, and taken it into account on installation of Oracle
  3. Decided that it's not as bad as it seems, and has disregarded it.

Initial reaction from our team is that setting passwords for the listeners would break backup scripts, apparently the listener is stopped for backups. Hardcoding passwords in these scripts is not really an option.

We are setting in place a plan for applying CPUs to the servers. But as I understand it, these vulnerabilities are not addressed by the CPUs.


S. Anthony Sequeira

Ralph's Observation: It is a mistake to let any mechanical object realise that you are in a hurry.
-- --
Received on Wed Apr 09 2008 - 11:52:55 CDT

Original text of this message