Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 47 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Pete Finnigan's Oracle security weblog


Home » Archives » November 2009 » Revoking PUBLIC Execute on SYS.DMP_SYS

[Previous entry: "PeteFinnigan.com Limited USA Partnership Announcements"] [Next entry: "OS Authentication"]

Revoking PUBLIC Execute on SYS.DMP_SYS

November 17th, 2009 by Pete


I saw today Pauls recent post to his blog "DAMS for Post and PRE-CPU Change Management" and when I read:
A quicker and simpler way to remove the threat of a vulnerable package is to simply REVOKE the PUBLIC EXECUTE on that package

I was concerned as simply revoking a PUBLIC execute privilege is not enough but luckily Paul went on to correct this by talking about applications breaking and dependencies; Paul rightly points out that SYS does not use PUBLIC EXECUTE itself when calling its own packages.

Revoking PUBLIC EXECUTE is difficult and will rarely close out an issue usually for two reasons; 1) revoking the PUBLIC EXECUTE will not stop someone executing the said vulnerable package IF it is used through another package and the issue is worse if the dependant package is executable by PUBLIC. 2) It also may be used without PUBLIC EXECUTE, i.e. another schema may use the feature/package via its own privileges (perhaps also via other packages).

Imagine if PACKAGE B and PACKAGE C use PACKAGE A (perhaps the vulnerable one) the simply revoking PUBLIC EXECUTE from PACKAGE A will not fix the issue unless you also revoke PUBLIC EXECUTE from PACKAGE B and C as well. What if PACKAGE A has EXECUTE granted to SCOTT, then SCOTT is also a target to exploit the vulnerability in PACKAGE A, less of a target than PUBLIC BUT still a target. If SCOTT didnt have privileges on PACKAGE A but has them instead on PACKAGE B or C then because all three packages in this simple example are all owned by one user then PACKAGE A is still accessible - there is a serious proviso that we must know to what extent PACKAGE B and C use PACKAGE A and if the vulnerable code is still exploitable.

The whole area of revoking PUBLIC privileges is fraught with problems; perhaps this is why Oracle dont simply revoke all of them!, static analysis of code is possible but only useful if all the code is static; if internal code in the database is dynamic and uses the vulnerable code then revoking privileges may cause unstable functionallity in the future.

Paul's suggestion to use Sentrigo Hedgehog to monitor the package SYS.DMP_SYS in his example is a good idea but monitoring needs to be ongoing and perhaps the a better solution than revocation is ongoing IDS/IPS techniques; of course a better solution is to apply the CPU.

If we take Paul's example of SYS.DMP_SYS we can investigate the relationships and privileges at a high level. Start with privileges assigned to SYS.DMP_SYS on 11.1.0.7 as an example:




SQL> @who_can_access

who_can_access: Release 1.0.3.0.0 - Production on Tue Nov 17 18:06:56 2009
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

NAME OF OBJECT TO CHECK [USER_OBJECTS]: DMP_SYS
OWNER OF THE OBJECT TO CHECK [USER]: SYS
OUTPUT METHOD Screen/File [S]: S
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]:
EXCLUDE CERTAIN USERS [N]:
USER TO SKIP [TEST%]:

Checking object => SYS.DMP_SYS
====================================================================



PL/SQL procedure successfully completed.


For updates please visit http://www.petefinnigan.com/tools.htm

SQL>




Rather interestingly there is no default PUBLIC EXECUTE privilege on this package on 11.1.0.7:




SQL> select * from v$version;

BANNER
-------------------------------------------------------------------
Personal Oracle Database 11g Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for 32-bit Windows: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

5 rows selected.

SQL>




Lets check for dependencies anyway on SYS.DMP_SYS to see if its functionallity has been exposed through any other packages:




SQL> @dep
Enter value for object_to_test: DMP_SYS
Enter value for owner_to_test: SYS

NAME OWNER TYPE
------------------------------ ------------------------------ --------------
DMP_SEC SYS PACKAGE BODY
DMP_SYS PUBLIC SYNONYM
DMP_SYS SYS PACKAGE BODY
DBMS_DM_MODEL_IMP SYS PACKAGE BODY
DBMS_DATA_MINING SYS PACKAGE BODY
DBMS_DATA_MINING_INTERNAL SYS PACKAGE BODY
DBMS_PREDICTIVE_ANALYTICS SYS PACKAGE BODY
DBMS_JDM_INTERNAL SYS PACKAGE BODY

8 rows selected.

SQL>




There are some packages that use (that is depend on) SYS.DMP_SYS that are granted to PUBLIC (in a real investigaation you would check all grants though not just PUBLIC). We can run a different script to isolate the PUBLIC grants on dependant packages of SYS.DMP_SYS. Remember that we ought to actually look at what is vulnerable in SYS.DMP_SYS and then check if that functionallity is exposed in the dependant packages although one approach may be to assume that any dependancy is dangerous independantly of the actual exposure. Lets look at the PUBLIC dependencies (in this case only on EXECUTE):




SQL> @dep_priv
Enter value for object_to_test: DMP_SYS
Enter value for owner_to_test: SYS

NAME OWNER TYPE
------------------------------ ------------------------------ ----------------
DBMS_DM_MODEL_IMP SYS PACKAGE BODY
DBMS_DATA_MINING SYS PACKAGE BODY
DBMS_PREDICTIVE_ANALYTICS SYS PACKAGE BODY
DBMS_JDM_INTERNAL SYS PACKAGE BODY

4 rows selected.

SQL>




OK, four packages. Lets check the exposure on one sample:




SQL> @get_tab2

get_tab2: Release 1.0.0.0.0 - Production on Tue Nov 17 19:09:02 2009
Copyright (c) 2004,2009, PeteFinnigan.com Limited. All rights reserved.

OBJECT TO CHECK [XXX_XXXX]: DBMS_DATA_MINING
SCHEMA/OWNER OF THE OBJECT TO CHECK [USER]: SYS
OUTPUT METHOD Screen/File [S]: S
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]:

Testing root object => [SYS.DBMS_DATA_MINING]


GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
SYS PUBLIC X

PL/SQL procedure successfully completed.


For updates please visit http://www.petefinnigan.com/tools.htm

SQL>




As predicted its just EXECUTE privilege to PUBLIC but it could have been granted to other schemas. As i said you would need to check out all dependencies, check code (unwrapper needed) and all direct grants to schemas if they exist.

Nice post though Paul, good food for thought!

November 2009
SMTWTFS
1234567
891011121314
15161718192021
22232425262728
2930     

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

Weblog Home
Weblog Archives


Home
Oracle Security Tools page
Oracle security papers
Oracle Security alerts

Web Development
SQL Server Security

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.0


Valid XHTML 1.0!