RE: Supplied Packages, Database Links, and SQL Injection

From: "MacGregor, Ian A." <ian@xxxxxxxxxxxxxxxxx>
To: "Stefan Knecht" <knecht.stefan@xxxxxxxxx>, <JHostetter@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 10 May 2006 07:57:14 -0700
Yes, but dba_dependencies needs to be checked and explicit grants made to users 
such as sysman where appropriate.

Ian

-----Original Message-----
From: Stefan Knecht [mailto:knecht.stefan@xxxxxxxxx] 
Sent: Tuesday, May 09, 2006 11:52 PM
To: JHostetter@xxxxxxxxxxxxxxxxxxxx
Cc: MacGregor, Ian A.; oracle-l
Subject: Re: Supplied Packages, Database Links, and SQL Injection

But be careful, I've encountered several situations where revoking privileges 
(according to oracle recommendation) breaks certain oracle components. One 
example is Grid Control, which recommends you to revoke several packages 
(utl_file, utl_tcp) from public, which in turn breaks Grid Control itself. 

Just my 2 cents.




On 5/9/06, Hostetter, Jay M <JHostetter@xxxxxxxxxxxxxxxxxxxx> wrote: 

        These are the standard revokes that I issue.  If a user needs it, I
        grant it directly to that user.  I put these revokes right into 
        postDBCreation.sql that is generated by DBCA.
        
        /* Revoke privileges per page 715 of the Admin Manual (Security
        Checklist).  */
        revoke execute on utl_smtp    from public;
        revoke execute on utl_tcp     from public; 
        revoke execute on utl_http    from public;
        revoke execute on utl_file    from public;
        revoke execute on dbms_random from public;
        
        /* From Oracle9i Application Developer's Guide - Fundamentals  Ch. 14 */
        revoke execute on dbms_obfuscation_toolkit from public;
        
        /* Oracle Database Security Benchmark v1.1 */
        revoke execute on dbms_lob from public;
        revoke execute on dbms_job from public;
        
        Some new revokes to consider: 
        
        /* Related to CPUApr2006 -
        http://www.red-database-security.com/advisory/oracle_cpu_apr_2006.html
        */
        revoke execute on dbms_reputil          from public; 
        revoke execute on dbms_snapshot_utl     from public;
        revoke execute on dbms_export_extension from public;
        
        You are right - it's fairly easy to find existing stored objects that
        will break if you make these revokes.  It's a bit more difficult for 
the 
        anonymous blocks.  I modified an old query for v$db_object_cache in an
        attempt to find out if one of these packages was called recently.  I'm
        sure somebody could improve upon it:
        
        select owner || '.' || name OBJECT 
                , type
                , to_char(sharable_mem/1024,'9,999.9') "SPACE(K)"
                , loads
                , executions execs
                , kept
        from v$db_object_cache
        where name in 
('UTL_SMTP','UTL_TCP','UTL_HTTP','UTL_FILE','DBMS_RANDOM', 
            'DBMS_OBFUSCATION_TOOLSKIT','DBMS_LOB','DBMS_JOB')
        order by owner, name
        ;
        
        Jay
        
        -----Original Message-----
        From: oracle-l-bounce@xxxxxxxxxxxxx 
        [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of MacGregor, Ian A.
        Sent: Tuesday, May 09, 2006 2:18 PM
        To: oracle-l
        Subject: Supplied Packages, Database Links, and SQL Injection 
        
        Certain supplied packages such as dbms_export_extension are flawed, you
        can inject SQL such as "grant dba to me;"  into them and the code will
        be executed.  Now suppose you are pulling data from a database which 
        includes sensitive information to one that does not via a database link.
        No sensitive data is accessible, the account on the sensitive database
        to which the database link connects has no privilege to access the
        sensitive objects.  However there is a package, I'll call it dbms_flawed
        which is exploitable via  SQL injection.  A user runs
        dbms_flawed.exeute_this@remote_db('grant dba to me')  thereby gaining
        that privilege or execute dbms_flawed.execute@remote_db('grant all on
        trusted_user.cofidential_info_table to me');  The controls setup to
        prevent improper access are bypassed.
        
        The answer is to to not allow "me" to execute dbms_flawed.  However, 
        there are other packages which might now or someday be exploitable.  How
        are folks handling this.  Have you revoked execute privileges from
        public from all packages, a certain set of packages (if so which ones)? 
        Is there a list of packages which have the potential to be exploited.
        Revoking privileges can be tricky.  Dba_dependencies will find  calls
        from stored procedures, but not anonymous blocks.
        
        
        
        Ian MacGregor 
        Stanford Linear Accelerator Center
        ian@xxxxxxxxxxxxxxxxx
        
        
        
        
        
        
        
        
        
        --
        //www.freelists.org/webpage/oracle-l 
        
        
        
        
        
        
        
        **DISCLAIMER
        This e-mail message and any files transmitted with it are intended for 
the use of the individual or entity to which they are addressed and may contain 
information that is privileged, proprietary and confidential. If you are not 
the intended recipient, you may not use, copy or disclose to anyone the message 
or any information contained in the message. If you have received this 
communication in error, please notify the sender and delete this e-mail 
message. The contents do not represent the opinion of D&E except to the extent 
that it relates to their official business. 
        
        --
        //www.freelists.org/webpage/oracle-l
        
        
        


--
//www.freelists.org/webpage/oracle-l
RE: Supplied Packages, Database Links, and SQL Injection

Other related posts:
