Pete Finnigan's Oracle Security Weblog

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 /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 /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!