Oracle Releases Another Mammoth Security Patch Update

For the second straight quarter this year, Oracle's latest critical patch update (CPU) released this week contained more than 400 security patches addressing vulnerabilities in a wide range of the company's product sets.

With 402 patches, Oracle's October 2020 CPU was slightly smaller than its previous one in July, which contained a record-breaking 444 security patches. But the October CPU addresses more security vulnerabilities across more products than the previous patch update.

The new CPU addresses 18 vulnerabilities in Oracle's core database technology. Sixteen of those flaws are remotely exploitable — four without the attacker needing to be authenticated to the system. The October CPU also included 46 patches for Oracle Fusion middleware, another important component of the company's Oracle E-Business Suite. Thirty-six of these flaws are remotely exploitable over the network, without the need for user authentication.

In total, Oracle's October 2020 CPU included patches for 28 product sets, including Oracle Big Data Graph, REST Data Services, TimesTen In-Memory Database, Communications Apps, Enterprise Risk Manager, and Financial Services Apps.

With the October CPU, Oracle for the first time also included patches for nonexploitable vulnerabilities in open source and other third-party components used in its various products. The change should make it easier for organizations to identify vulnerabilities that are not exploitable in the context of any given Oracle product distribution, said Eric Maurice, Oracle's director of security assurance, in a blog.

"Oracle’s goal is to simplify the interpretation of the advisory and enable customers to clearly identify issues that are potentially exploitable," Maurice said.

According to an analysis by application security firm Waratek, some 20 of the product sets impacted in the October update contain vulnerabilities with a critical severity rating of 9.8 or 10. Troublingly, 100% of the vulnerabilities in Java SE that were addressed with this month's patch update can be remotely executed with user credentials. The same is true of 93% of the vulnerabilities patched this week in Oracle E-Business Suite, 80% of those in PeopleSoft, and 78% in Fusion Middleware.

"This CPU reflects the usual ebb and flow of vulnerability research," says John Adams, CEO at Waratek. While some Oracle CPUs, like the one in July, were huge, the number of impacted products was less. "This CPU is smaller, but still large, and effects more products with higher risk vulnerabilities," he says.

What organizations need to be paying attention to with this CPU is the high percentage of bugs that are remotely executable across the entire product set, Adams says.

Oracle Fusion Middleware alone, for instance, has 18 newly disclosed vulnerabilities with a severity rating of 9.8. Such flaws should receive high priority from teams that maintain the products, he notes.

The Patching Challenge
As one of the world's largest enterprise software and services vendors, Oracle's technologies are widely deployed in organizations around the world. Many of its products — especially its database technologies — power business-critical workloads at many of the world's largest companies.

Even so, many organizations have been relatively slow to deploy patches like the ones the company announced this week because of multiple issues. According to Adams, by Oracle's own admission its average customer takes six or more months to fully deploy a CPU across the enterprise — despite the fact that attackers are able to often exploit newly disclosed vulnerabilities in just hours or days, he says.

One reason is the sheer mammoth size of some of Oracle's CPUs Adams notes. Though an organization might need just some of the patches in an update, they are forced to take the entire set. This can create challenges and potentially even disruption of functionality to mission-critical systems. 

"The risk of disruption is very concerning for most companies we speak with," Adams says.

Another big issue is downtime. Most organization cannot afford the disruption associated with patch deployment — especially on customer-facing applications. They therefore tend to deploy new patches in nonproduction environments and then test them for compatibility before rolling them out to a production system.

"All of this effort, coupled with lining up the resources to administer the updates, often takes months to coordinate."

Avi Shua, CEO and co-founder of Orca Security, says patching critical systems — especially technologies like Oracle DB and VM VirtualBox — are critical but also problematic.  

"Customers need to run thorough tests with their entire ecosystem before rolling to production," Shua says. "In some cases, they cannot move to an updated version prior to ensuring all ecosystems support the new version."

Shua says he has encountered situations where organizations had to choose between patching a critical flaw or leaving it open and risk being out of support for up to nine months because they were using a product not certified with new versions.

"Besides the standard recommendation to patch, I believe that it is just as important to make sure you have a well-understood topology of your environment," Shua says. "Preferably, this can be gathered by automatic tools, which also allow for risk prioritization based on your context."