Imperva CTO Amichai Shulman on Oracle's latest critical patch update (CPU).
This is a standard patch. However, quite a large volume of patches are dedicated to the MySQL database which is a new introduction into Oracle's CPU process. Overall, there are 78 vulnerabilities which is consistent with previous releases. However, considering Oracle added MySQL to the patching process, this number seems low.
- There is a bottleneck in the Oracle patching process. If you were to introduce a new product, there should be more vulnerabilities overall in the CPU--but this didn’t happen. Could there be obstacles in the security and testing process? While introducing MySQL into the patch process is a good thing, it emphasizes again scalability problems. With the introduction of a new product, especially when it shows 27 fixes in this CPU, you'd expect the number of overall patches in the CPU to increase. This has not happened. For example, the Oracle DB server product only shows two fixes.
- There are only two vulnerabilities in the database product. Why? Either the database server has reached an amazing maturity in terms of security or Oracle did not have enough resources to include more fixes into the process. This may be a consequence of adding the new MySQL product in the patching process. However, another factor may be that these fixes are much more critical and complex than their CVSS score suggests.
- Oracle continues to undervalue the severity of their reported vulnerabilities. For example, the vulnerability described in InfoWorld is CVE-2012-0082 only gets a 5.5 on the severity scale. As another proof point, one Solaris vulnerability (CVE-2012-0094), scores a 7.8 but is very similar to issues Oracle database server and MySQL products that scored just a 5.5.
- Other stuff: Other than that there are many fixes in HTTP based components of the Oracle product line.
What does this release tell us to expect from Oracle security in 2012?
- Severity scores will continue to be misleading. Oracle should rethink their "Partial+" ranking which artificially plays down the severity.
- Vulnerability bottleneck. They should fix this bottleneck, especially as they introduce new products and acquisitions continue. We assume the bottleneck exists due to the relative low num of vulnerabilities while the patch increases in terms of products covered. As in many organizations, it’s safe to assume that Oracle has a security team separate from the engineering team that deals with the vulnerabilities and so the bottleneck most likely resides there and should be removed.