Or, alternatively, you could live EXTPROC where it is, no matter how
wulnerable it is, and trust a good firewall. If you are in a commercial
environment, breaking in a box through the buffer overflow hole would
require a major talent, which is very hard to come by in these days of
cost cutting. I suggest that if anyone behind the firewall breaks in through
that hole, that he's given a promotion to the senior programmer position
and a hefty raise.
On 2003.07.29 11:29, Arup Nanda wrote:
> I sent a reply on that day. Here it is, once again.
>
> Date: Fri, 25 Jul 2003 12:25:59 -0400
> Subject: Re: Question about EXTPROC and vulnerability
>
> Hemant,
>
> You are right in wondering why there are three steps.
>
> 1. The lsitener must not be listening for the EXTPROC connections - that is
> the first line of defense.
> 2. There is no absolute need to remove from tnsnames.ora, but good to do so
> as you will see later.
> 3. The executabe has to be removed as it could be exploited in a different
> manner. Note, all security alerts are based on what is known _today_; not
> what is possible. Just because the listener is not listening for the extproc
> executable does not _necessarily_ indicate that it can't be used in an
> attack; an enterprising hacker may find a way. If your intention is to
> remove extproc, you did so by removing from listener.ora; so it is just
> prudent to remove the last potential hole by removing "extproc" executable,
> too. After all, it not useful.
>
> Now for the other question why the alter 57 does not talk about the
> listener.ora security. The alerts 29 and 57 are similar, yet different. The
> alert 29 talks about a "buffer overflow" using the external process. The
> alert 57 is about system privileges. The system privilege, create library
> will alow a hacker to create a library on "any" filesystem that the user
> oracle has privileges on, INCLUDING THE ORACLE_HOME/BIN and $OH/lib!
> Therefore, imagine a hacker breaks in, creates a library that uses the
> Oracle excutables and java libraries and executes them. This is a huge hole
> and should be plugged by simply disallowing any user to create a library.
> Take for instance, a user has to create a library to create a function for
> some complex mathemetical calculation, e.g. finding the prime numbers, which
> can't be done in PL/SQL. This can be done via a C++ program and the shared
> object can be made availabel to ORacle using a lbrary as:
>
> create library prime_num_lib as '/usr/ananda/lib/prime_num_lib.so';
>
> When a user uses this library, the EXTPROC process will run the .so file on
> the user's behalf. Fair enough; what's wrong with that?
>
> What is the user (the hacker) creates a library to point to some .so file in
> $OH/lib directory? You get the picture what might happen.
>
> Another variation of the create library is
>
> create library prime_num_lib as '/usr/ananda/lib/prime_num_lib.so' AGENT
> 'dblink1'
>
> Here the Oracle server process uses the dblink to connect to another
> server's EXTPROC process to executes its task. Instead of using a dblink to
> another server, it may actually connect to the extproc of the same server
> using the connect string defined in the tnsnames.ora. It may not exist; but
> what if the hacker actually copied the exeutable to a different name,
> seemingly harmless. Removing extproc from tnsnames.ora wil lplug that hole
> too. BEsides, it is a good practice to remove it since the presence
> indicates the usage (albeit in the past) and may give a potential hacker a
> clue.
>
> Remember, securing is not just plugging the most obvious holes; but all
> potential ones. The alerts point that out.
>
> Another thing of note here is to plug a seprate potential problem - removing
> the CREATE ANY DIRECTORY privilege. This provilege creates a directory on
> any filesystem accessible by oracle user. Do not grant any one this
> privilege; and be very cautious while granting CREATE DIRECTORY privilege,
> too.
>
> HTH.
>
> Arup Nanda
> www.proligence.com
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Tuesday, July 29, 2003 10:59 AM
>
>
> >
> > Resending this email, hoping for a reply this time.
> >
> > >Date: Fri, 25 Jul 2003 07:49:24 -0800
> > >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > >X-Comment: Oracle RDBMS Community Forum
> > >X-Sender: Hemant K Chitale <hkchital_at_singnet.com.sg>
> > >Sender: ml-errors_at_fatcity.com
> > >Reply-To: ORACLE-L_at_fatcity.com
> > >From: Hemant K Chitale <hkchital_at_singnet.com.sg>
> > >Subject: Question about EXTPROC and vulnerability
> > >Organization: Fat City Network Services, San Diego, California
> > >
> > >
> > >Oracle's Security Alert #29 [Note 175429.1] on the EXTPROC recommends
> the
> > >workaround to disable
> > >EXTPROC as
> > > 1. Removing the entry for extproc/PLSExtproc/icache_extproc from the
> > > listener.ora
> > > 2. Removing the entry from the tnsnames.ora
> > > 3. Renaming or removing the extproc executable
> > >
> > >Why should all three actions be necessary ? Why not just removing the
> > >entry from the
> > >listener.ora ? Can extproc be called without the listener configured ?
> > >
> > >Security Alert #57 just talks of the CREATE LIBRARY privilege and makes
> no
> > >mention of
> > >updating the listener.ora or tnsnames.ora or removing/renaming the
> extproc
> > >executable. Why ?
> > >Is it that Oracle wants people to use EXTPROC [or makes use of EXTPROC
> > >itself] so it
> > >does not specify how EXTPROC can be disabled ?
> > >
> > >
> > >
> >
> > Hemant K Chitale
> > Oracle 9i Database Administrator Certified Professional
> > My personal web site is : http://hkchital.tripod.com
> >
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Hemant K Chitale
> > INET: hkchital_at_singnet.com.sg
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> >
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Arup Nanda
> INET: orarup_at_hotmail.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: mgogala_at_adelphia.net
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Tue Jul 29 2003 - 13:14:23 CDT
