Pete Finnigan's Oracle Security Weblog

I came across this post to the ORACLE-L list this morning. This poster describes his nightmare of installing hundreds of patches for Alert 68. He also says that he and his colleagues have now started to think about hacking and what can cause database disruptions:

"after the NIGHTMARE we had over here with applying patches for security alert
#68 (hundreds of them) we started
thinking more about 'hacking' and what else could cause database service
disruptions.
One of the things I am still worried about are to GRANTS to public after a
database creation (9.2.0.6)."

This is good from one point of view in that customers of Oracle are now taking security seriously and not just thinking about applying patches but also thinking about how else their data might be in danger. This is good. He goes on to show a simple test of how he disrupted the database with a login that just has CREATE SESSION privileges.

This issue and many more are due to the fact that Oracle ship their software so that when its installed each user inherits a large amount of access privileges to features and functions owned by SYS and other users that have had access to them granted to PUBLIC. I talked about the PUBLIC user group recently in this blog.

I believe that Oracle should seriously look at reducing the privileges granted to PUBLIC in future releases of their database software or at least provide an option / mechanism in the installation process that allows the removal of a large part of the PUBLIC privileges if the customer so chooses but does so so that the rest of the software doesn't break - I know that is the hard part!