Yet another security alert

Days ago I found the following on the Web:
http://www.red-database-security.com/advisory/oracle_modify_data_via_views.html
where it says few words about serious security vulnerability which affects all versions of Oracle from 9.1.0.0 to 10.2.0.3. Briefly speaking, the main issue is that any user with SELECT privilege on another user’s table can insert/delete/update rows in that table via specially constructed view. They also mentioned Metalink note 363848.1 which is not accessible now for public user, probably due to security reasons.
As an immediate workaround, it was recommended to sanitize the CONNECT role by removing the CREATE VIEW (and CREATE DATABASE LINK) privileges from that role as well as revoking unnecessary CREATE VIEW privilege from user accounts.

So at first sight, it may seem that DBAs have an acceptable temporary solution to this problem. But recently I discovered that situation is much more disastrous. I was “lucky” to construct INSERT/UPDATE/DELETE statements which make it possible to update another user’s table without even creating any views. Thus, no special privileges are needed: a malicious user with a single CREATE SESSION privilege can modify tables in database while having only SELECT grants on those tables.

Unfortunately, it’s not a fake and the following test script proves that. Those DML statements were removed because I think this kind of knowledge should never be published for everyone’s sight.


SQL*Plus: Release 9.2.0.6.0 - Production on Sun Apr 16 17:49:00 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> conn / as sysdba
Connected.
SQL>
SQL> create user user1 identified by user1
2 default tablespace users
3 quota 10M on users;

User created.

SQL> grant create session, create table to user1;

Grant succeeded.

SQL> create user hacker identified by hacker;

User created.

SQL> -- Only CREATE SESSION is granted to hacker
SQL>
SQL> grant create session to hacker;

Grant succeeded.

SQL> conn user1/user1
Connected.
SQL>
SQL> -- Create table in USER1 schema
SQL>
SQL> create table test (x int primary key, y varchar2(10));

Table created.

SQL> insert into test
2 select 1, 'One'
3 from dual
4 union all
5 select 2, 'Two'
6 from dual;

2 rows created.

SQL> -- Grant SELECT on table to "hacker"
SQL>
SQL> grant select on test to hacker;

Grant succeeded.

SQL> conn hacker/hacker
Connected.
SQL>
SQL> select * from user1.test;

X Y
---------- ----------
1 One
2 Two

SQL> -- This will fail, as expected
SQL>
SQL> update user1.test
2 set y = 'I AM HERE!'
3 where x = 1;
update user1.test
*
ERROR at line 1:
ORA-01031: insufficient privileges


SQL> -- Ouch...
SQL>
SQL> update
2 <... censored ...>
...

1 row updated.

SQL> select * from user1.test;

X Y
---------- ----------
1 I AM HERE!
2 Two

SQL> rollback;

Rollback complete.

SQL> select * from user1.test;

X Y
---------- ----------
1 One
2 Two

SQL> -- This will fail, too
SQL>
SQL> delete from user1.test
2 where x = 1;
delete from user1.test
*
ERROR at line 1:
ORA-01031: insufficient privileges


SQL> -- Ouch-ouch...
SQL>
SQL> delete from
2 <... censored ...>
...

1 row deleted.

SQL> select * from user1.test;

X Y
---------- ----------
2 Two

SQL> rollback;

Rollback complete.

SQL> select * from user1.test;

X Y
---------- ----------
1 One
2 Two

SQL> -- This will fail, of course
SQL>
SQL> insert into user1.test
2 values (3, 'I AM HERE!');
insert into user1.test
*
ERROR at line 1:
ORA-01031: insufficient privileges


SQL> -- But...
SQL>
SQL> insert into
2 <... censored ...>
...

1 row created.

SQL> select * from user1.test;

X Y
---------- ----------
1 One
2 Two
3 I AM HERE!


Being sure that Oracle Corp. should fix this issue as soon as humanly possible, I’ve opened “severity 1” TAR on Metalink. Oracle Support personnel replied immediately that they are aware of that problem and it will surely be solved by April 2006 CPU planned for next week.

Note: I published this info here not to shed a light on Oracle Corp. and their products. It’s here just to warn DBAs and management staff that extremely high precautions should be taken until this issue is fixed.

Andrew.