A security research firm based in Argentina, Argeniss, had announced a plan to publicly disclose an unfixed Oracle Database security bug every day for a week in December - "The Week of Oracle Database Bugs." A disclosed unpatched security bug is referred to as a 0-day (or zero day). Argeniss' motivation is "to demostrate Oracle isn't getting any better at securing its products."
Yesterday, Argeniss announced that they have suspended their plan "due to many problems." It is unclear as to why they have suspended it, but based on the publicity generated I think "postponed" may a more operative word.
This event highlights two key points -
- There are hundreds of unpatched security bugs in the Oracle products, thus the Critical Patch Updates (CPUs) will continue for the foreseeable future. You should plan for the same type of complex and bulky CPUs until at least April 2008. Since the CPUs will keep coming, all organizations need to have a well defined and executable security patch process in place in order to deal with the CPUs in an efficient and timely manner.
- Most organizations don't apply the CPU patches for at least 45-120 days after release, therefore, usually there are 20-60 unpatched security vulnerabilities in an average Oracle database. For about 25% of the fixed database vulnerabilities in a CPU, detailed and workable exploit code is released. The release of seven new zero-day vulnerabilities really doesn't impact much the security of most organizations as there are already a significant number of unpatched vulnerabilities. Also, seldom are the Oracle Database vulnerabilities remotely exploitable without proper database authentication. Organizations should not be overly reacting to this event rather a comprehensive plan and procedure should be put in place to apply CPU patches in a timely manner and to harden all databases and application, which will improve security much more than overly reacting to these type of public disclosures.