Re: Resend : Question about EXTPROC and vulnerability

You are welcome. Another role that has the CREATE ANY DIRECTORY system priv is the IMP_FULL_DATABASE. In addition the users of Intermedial MDSYS, CTXSYS, etc, have that privilege too. you should watch out for those roles and users.

Arup Nanda

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Wednesday, July 30, 2003 11:14 AM

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

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