Oracle CPU Contains Lowest Number Of Database Fixes Ever

Oracle's Tuesday release of its Critical Patch Update (CPU) garnered a continuation of criticism from the database security community, with researchers pointing to a mounting list of unfixed vulnerabilities that date back to 2009, even as Oracle's rate of releasing database patches continues to plummet. Not counting MySQL updates, which are primarily handled by the open-source community, only two out of the 78 fixes in yesterday's CPU were database-related, the lowest number released by Oracle since it started quarterly CPU releases.

"I am honestly shocked that they only fixed two database vulnerabilities," says Alex Rothacker, manager of Application Security Inc.'s research arm, TeamSHATTER.

According to Rothacker, his firm currently has nine vulnerabilities reported in Oracle's queue of discovered vulnerabilities. While that might not seem like a lot on its face, he says, one of them dates back to 2009 and five of them can result in privilege escalation. In addition, that's only the vulnerabilities discovered by AppSec researchers. Based on his conversations with those in the community, Oracle has been notified by other vendors and independent researchers about many other vulnerabilities, as well.

"There's definitely more stuff out there than just those nine," Rothacker says.

Rothacker says that because many Oracle customers are loathe to make fixes in their databases anyhow, this lack of pressure is what allows the firm to "get away with taking its time on these CPUs."

Wolfgang Kandek, CTO of Qualys, tends to agree that the slow speed at which database patches are generally applied could contribute to Oracle slowing down its pace with these updates.

"Database patching is definitely slower than other areas, such as servers or workstations," he says. "You can find vulnerabilities and Oracle can fix them, but if customers do not install them or come back to Oracle and say, 'This is important for me,' it makes sense that Oracle could maintain that flow of patch schedule. The rollout schedule is a reflection of how much users actually pay attention to those things."

However, Amichai Shulman, CTO of Imperva, believes there is a bottleneck in the Oracle patching process that needs fixing.

"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," Shulman says. "We assume the bottleneck exists due to the relative low number 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."

He says the low number of database fixes in this CPU should have Oracle users' antennae up about those particular fixes because they could be bigger problems than the update notes suggest.

"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," Shulman says. "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."

In addition to the low number of database patches included in recent CPUs, database security researchers have been critical of the way Oracle has rated the severity of database vulnerabilities of late.

"Oracle continues to undervalue the severity of their reported vulnerabilities," Shulman says. "One Solaris vulnerability [CVE-2012-0094] scores a 7.8 but is very similar to issues in Oracle database server and MySQL products that scored just a 5.5. "

Last spring, Rothacker wrote a blog post calling Oracle to task over its narrow interpretation of the CVSS definition of vulnerabilities considered "Complete" as it relates to databases, which can cause discrepancies like the one Shulman pointed out.

"According to Oracle, a vulnerability’s impact is only considered 'Complete' if 'all software running on the machine' is affected, not just the Oracle Database Server. This runs completely contrary to the official CVSS definition, not to mention -- common sense," he wrote then. "Now, any vulnerability that would usually be considered 'Complete,' but doesn’t fit Oracle’s narrow definition, is rated by Oracle as ‘Partial+’. "

Rothacker stands by his criticism following this CPU release, stating that the Partial+ rating is "Oracle's way of messing with CVSS."

Shulman agrees, stating that if this CPU is any indication, Oracle's database severity scores will continue to be misleading.

"Oracle should rethink their Partial+ ranking, which artificially plays down the severity [of vulnerabilities]," he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.