Re: Listener Vulnerabilities - how to address them

1. 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.
2. There really is no reason to not password project your listener and set ADMIN_RESTRICTIONS=ON
   • regarding backup scripts (aside from the 'why'), accounting for a password protected listener can be handled in two ways.
3. modify the backup scripts to use a HERE document and set the password
4. less elegant approach is to just kill the listener process.

Bradd Piontek
piontekdd_at_gmail.com

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.
>
>
> http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_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.
>
> Anyone?
> --
> S. Anthony Sequeira
> ++
> Ralph's Observation:
> It is a mistake to let any mechanical object realise that you
> are in a hurry.
> ++
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l