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 18.104.22.168 as an example:
Rather interestingly there is no default PUBLIC EXECUTE privilege on this package on 22.214.171.124:
Lets check for dependencies anyway on SYS.DMP_SYS to see if its functionallity has been exposed through any other packages:
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):
OK, four packages. Lets check the exposure on one sample:
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!