|
Services
Information
Company
|
Read-only user can modify data via views
Preface Last 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.0 to 10.2.0.3. 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 (9.2.0.0-10.2.0.3) exists an unpatched vulnerability which allows users with “SELECT” only privileges on a base table to insert/update/delete data via a specially crafted view. The impact of this vulnerability on the Oracle data dictionary is low because most data dictionary tables don’t have a primary key which is a requirement for this vulnerability. The impact on custom applications can be huge and 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). If these low-privileged users are able to create a view, which is standard in Oracle 9.2.x to 10 g R1, they could also insert, update and delete data via a specially crafted view. Depending on the architecture, it is possible to modify data, escalate privileges, … Patch Information Currently there are no patches available. According to Oracle secalert Oracle will provide patches in a future critical patch update. Red-Database-Security is not convinced that the April 2006 CPU will contain patches against this vulnerability. Test case 1 (without the view) The user dbsnmp has only the privilege "SELECT ANY DICTIONARY". dbsnmp can't update tables in the data dictionary C:\>sqlplus dbsnmp/dbsnmp SQL*Plus: Release 10.1.0.4.0 - Production on Thu Apr 8 19: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> -- deleting data from the data dictionary does not work (as expected) SQL> delete from sys.registry$; delete from sys.registry$ * 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> -- Dropping data via the view works !!! ==> security issue !!! SQL> delete from e; 17 rows deleted. 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 Sanitize the connect role (9i - 10g R1) and remove the CREATE VIEW (and CREATE DATABASE LINK, …) privilege from the connect role. Removing the primary key from the base table solves the problem too. Be aware that this could cause performance and integrity issues on the application. The Oracle Metalink note recommends creating views the option “WITH CHECK OPTION”. This recommendation helps against accidental modification but not against hackers. Credits Special thanks to Jens Flasche who made Red-Database-Security aware of the Metalink note and for the first analysis + additional test cases. 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 Timeline 1.00 - 10-apr-2006 - initial version 1.01 - 10-apr-2006 - Credits for the original founder added. © 2006 by Red-Database-Security GmbH - last update 10-apr-2006 |
