Exploits and revoking the risks of revoking PUBLIC

Oracle DBAs should be aware of the latest exploit published for Oracle 10g and 11g.

The advice given was to revoke some privileges from public. There has been discussion about the number of grants to public and the practicalities of revoking them (eg here).

I feel it is worth giving an overview of public grants and security.

When Oracle wants to give users functionality (eg export), they can go about implementing it in two ways. Firstly, they can build a powerful set of code that runs with SYS or SYSTEM privileges. Because of the potential for that power to be exploited by naughty code, they'd have to build in a lot of checks to block off undesirable effects. They need to try to predict the possible inputs and where they might cause an issue.

The other approach is to have the code run with the user's privileges. That way they can, in theory, miss out a large proportion of those checks. The drawback of this approach is evidenced in this exploit. The user has to be given authority on all the dependencies of the code 'entry point'. So here DBMS_JVM_EXP_PERMS is an undocumented package. As such there is no reason for a user to ever execute it directly, and the intention is that no-one should be executing it. The reason that PUBLIC has been granted execute permission on it is that it is called by another package (presumably DBMS_JAVA, but possibly others such as import) which runs with user's privileges.

You cannot assume that because you do not call something directly it would be safe to revoke PUBLIC privileges on it.

The difficulty with revoking public privileges is that it is very difficult to determine what will break. It may not be a package that breaks, but any Oracle supplied code (eg expdp, log miner, external tables, advanced queuing...). It is safe to assume that Oracle only tests its databases with all those PUBLIC permissions in place. It is also safe to assume that, if you revoke a privilege, something will break. It may well be something you don't use. Given that Java is not present in Express Edition, you'd probably be safe in assuming everything you could do in XE would still work with Java disabled.

But great care should be taken before revoking any default PUBLIC grant, and it should be accompanied by testing as much as possible, of both applications and DBA related tasks (including DR, backup/recovery, database alerts, auditing and anything else you rely on).

This is a dangerous exploit and it will be interesting to see Oracle's response (and whether it comes in the next CPU). David Litchfield is retiring from the Oracle security field which could case a shadow over his decision to release this exploit in advance of any fix.