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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >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 <[EMAIL PROTECTED]> > > > >X-Comment: Oracle RDBMS Community Forum > > > >X-Sender: Hemant K Chitale <[EMAIL PROTECTED]> > > > >Sender: [EMAIL PROTECTED] > > > >Reply-To: [EMAIL PROTECTED] > > > >From: Hemant K Chitale <[EMAIL PROTECTED]> > > > >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: [EMAIL PROTECTED] > > > > > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > > >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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
