Oracle delivered its quarterly montage of patches and updates this week. The quarterly release cycle--like Microsoft's monthly Patch Tuesday--is designed to provide some stability and predictability for the IT admins who have to test and implement the patches, but at least one security expert thinks the Oracle system needs some work.
The January 2011 CPU (critical patch update) from Oracle addressed a total of 43 Oracle security vulnerabilities, and another 23 related to Sun software. It is a bit on the low side compared with recent CPUs, but still within the realm of normal for an Oracle quarterly update. So, why is that a problem?
Amichai Shulman, CTO of Imperva--a Web and database security company--has reviewed the Oracle CPU and provides the following analysis. "Oracle patching needs fixing."
Shulman elaborates, "The quarterly patch cycle has seen a slowdown in fixing database vulnerabilities since the acquisition and incorporation of so many companies and products during the past year. I can't believe there is only one database fix quarter-to-quarter when there must be dozens or even hundreds of vulnerabilities," adding, "In the past, when Oracle had far fewer products, they would patch 100 database vulnerabilities at a time. One would assume that more products require more fixes, yet we are seeing smaller patches with less fixes for more products."
To that point, during the two year timeframe that Oracle has been following the quarterly patch update cycle, it has also acquired an additional fourteen companies including Virtual Iron and Sun Microsystems. It seems reasonable to expect that incorporating products and tools from fourteen new companies should make the vulnerability and patch count increase. To be fair, though, Java updates are not included in these numbers because Oracle has established a separate update cycle dedicated to Java.
Shulman also takes issue with the lack of clarity or disclosure from Oracle. Oracle has chosen to make it a policy not to elaborate on vulnerability details, citing concerns that hackers would use the information to develop exploits. However, attackers probably knew about the holes before Oracle, and have the ability to reverse-engineer the patch to find the root vulnerability, so really it is only Oracle customers who are left in the dark without the information necessary to make informed risk assessments.
"Without such insight, Oracle customers cannot develop a work-around for their production application and I find it hard to believe a company would patch critical applications without months of testing," proclaims Shulman. "This lack of transparency is outrageous behavior. Vendors expect researchers to share details with them responsibly, yet they fail to do the same with security vendors and their customers."
Stability and predictability in the update process is a good thing, but perhaps quarterly is not frequent enough for an organization like Oracle to meet the demand of vulnerability patching necessary for the range of products and technologies it has to address. There comes a point where the vulnerabilities that are left unpatched are bigger news than the flaws that are fixed, and customers are left in limbo to fend for themselves until the next update.