Re: Resend : Question about EXTPROC and vulnerability

Thanks Arup. It is a bit clearer now.

I do not grant CREATE LIBRARY privileges explicitly but these would be part of the DBA role and I've seen the DBA role being granted all to easily. My guess is that some of the "seeded" demo schemas in 9i also have such privileges. Here, again, I never install the demo schemas.

Regards
Hemant
At 07:29 AM 29-07-03 -0800, you 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).

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).