Imperva slams Oracle patching methods… again

Imperva CTO Amichai Shulman has once again criticised Oracle’s patching process after the company announced an update that would fix a slew of vulnerabilities across hundreds of products.

Oracle’s security update included 78 fixes for Oracle Database 10g and 11g, Fusion Middleware 11g, Application Server 10g, WebLogic Server, PeopleSoft Enterprise CRM, HRM and PeopleTools, JDEdwards, MySQL and Oracle Sun Product Suite, products that stretch across Oracle’s portfolio.

A number of the vulnerabilities were remotely exploitable without authentication, Oracle said, which means they could be exploited over a network without the need for a username and password.

Shulman however has questioned why only two vulnerabilities in the database product were fixed and suggested that the company didn’t have enough resources to make all the fixes needed.

"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," he wrote. "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."

Adding MySQL into the patch process is a "good thing" but it does raise more questions about Oracle’s patching process, Shulman added.

"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," he said. "Could there be obstacles in the security and testing process?"

"While introducing MySQL into the patch process is a good thing, it emphasises again scalability problems," he said. "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."

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

This time last year Shulman criticised Oracle’s patching methods, saying the system needed fixing and that Oracle should look at releasing updates more often than every quarter.

Type: White Paper


  • Favorite list is empty.
FavoriteLoadingClear favorites

Your favorite posts saved to your browsers cookies. If you clear cookies also favorite posts will be deleted.