Re: Listener Vulnerabilities - how to address them
Date: Wed, 9 Apr 2008 11:32:27 -0500
- the easiest exploit , in my opinion, regarding listeners prior to 10g is the ability to be able to remotely shut down the listener from any client that as access to lsnrctl. Very simple DOS attack.
- There really is no reason to not password project your listener and set
- regarding backup scripts (aside from the 'why'), accounting for a password protected listener can be handled in two ways.
- modify the backup scripts to use a HERE document and set the password
- less elegant approach is to just kill the listener process.
On 4/9/08, Tony Sequeira <tony_at_sequeira.org.uk> wrote:
> Hi All,
> Most of you are probably aware of the following document, or similar.
> 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
> 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
> 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.