Preparing for Oracle’s April Critical Patch Update

At the start of 2020 we wrote about the Vulnerability Fujiwhara, warning organizations about the flurry of disclosures coming their way. The three Fujiwhara events that year, where Microsoft’s Patch Tuesdays collided with Oracle’s quarterly Critical Patch Updates (CPU), accounted for 7% of all 2020 vulnerabilities. At the same time, security teams faced COVID-19, increased cybercrime, and layoffs. Since then, the volume of vulnerability disclosures has seemingly returned to normal. However, new events like CISA’s BOD 22-01 (including the Known Exploited Vulnerabilities (KEV) Catalog) and the Ukraine-Russia War have not granted security teams a reprieve. While organizations are dealing with these challenges, what can they do to prepare for the forecasted 450+ Oracle vulnerabilities every quarter?

Oracle CPUs may not be as scary as you think

For those unfamiliar, Oracle releases their CPU every quarter to fix vulnerabilities across their substantial product line. Because it is done quarterly, instead of Microsoft and many other vendors’ monthly Patch Tuesdays, Oracle’s batch of fixes tends to be extremely large. April’s upcoming release is rumored to contain up to 450 patches, many likely being for high and critical vulnerabilities, so security teams will have their hands full.While news headlines and even Oracle’s own pre-CPU announcements make it sound extra scary, the risks included in Oracle releases are often not new. Looking back in January, news articles warned that 483 new patches were being released. And even though the patches were “new”, the actual number of new vulnerabilities disclosed was far fewer, totaling 158 – only 32% of that headline number. The rest had been published days, weeks, and years prior. Yes, you read that right, years! The oldest vulnerabilities in January’s CPU were included 4,347 days late, having originally been disclosed on December 13, 2013.

A closer look at Oracle’s January CPU

Taking a closer look at Oracle’s January CPU, we see that one software (MySQL) was responsible for a bulk of the new vulnerability disclosures:

Where did the rest of the vulnerabilities come from? That answer involves third-party libraries. A vast majority were disclosed in third-party libraries used by Oracle software. Some examples include Apache HTTP Server, Apache Log4j, CKEditor, PHP, Node.js, and OpenSSL. The rest were disclosed in Oracle’s own software but without a patch being available. Unfortunately, that means affected Oracle software will likely remain vulnerable for a long time. Although an official patch may not be present, there are ways to minimize risk.

The best way to do that is by understanding the vulnerabilities. Having a Software Bill of Materials (SBOM) helps tremendously, whether it is from the vendor, or built in-house over time using prior disclosures and patches as the corpus. With it, organizations will have a better understanding of vulnerability disclosures and how they affect products, even if vulnerability researchers are ambiguous in their descriptions. For example, if a new issue is disclosed in a third-party library like Log4j, organizations with an up-to-date SBOM will know which of their big commercial packages rely on it, and are therefore affected.

Having an SBOM with that kind of understanding would have been a game-changer back when Log4Shell was first discovered in late November. Yes, some of the difficulties in triaging/remediating resulted from the confusion created by multiple subsequent vulnerabilities and fixes, but since the release of version 2.17.0, some organizations are still having trouble patching. The main culprit being vendor disclosures and their ambiguity or poorly worded advisories. Too many vendors have published conflicting information, stating in their advisories that their product is “not affected by Log4Shell”, yet later on noting that the software does indeed run on a compromised version of Log4j. With an SBOM powered by proper vulnerability intelligence, you can likely make those connections and better secure your systems more quickly.

The bad news: You’ve likely been at risk for a while

Since only 32% of January’s 2022 were new vulnerabilities, organizations might find some relief in knowing that their actual workload may be much lower than they initially thought. However, the bad news is that you’ve probably been vulnerable for quite some time.

Examining past Oracle CPUs

Using the chart below, we can see a breakdown of all quarterly CPUs in the past two years showing total patches versus new disclosures:

Aside from January 2020’s CPU, the proportion of new vulnerabilities tends to fall between 32% to 49%, but organizations shouldn’t default to relegating “old” issues to the backlog. Regardless of its age, a vulnerability still poses a risk; especially ones from Oracle. The KEV Catalog was specifically created to alert organizations to issues that are actively used by malicious threat actors, and if you run a search in CISA’s Known Exploited Vulnerabilities Catalog, every single Oracle CVE ID was assigned prior to 2021, with the oldest being 2008.

Prioritize exploitable vulnerabilities first

If your organization is relying on publicly sourced data, we’d recommend Vulnerability Managers monitor the KEV Catalog and cross-reference April’s release with it before prioritizing begins. By doing this, you can focus on those exploitable issues first while complying with CISA’s Shields Up initiative. There is a good chance that the upcoming CPU will include patches tied to the ongoing Russia-Ukraine conflict. CISA added several Oracle vulnerabilities on March 3, which our analysts then tied to several Russian hacking groups such as Fancy Bear and Cozy Bear.

Better data enables better risk decisions

For organizations that have access to comprehensive vulnerability intelligence, their process will be more robust. After referencing April’s CPU to the KEV catalog and using metadata, organizations should identify issues that have a public exploit and documented solution information while being remotely exploitable. With that, security teams can then conserve resources by prioritizing vulnerabilities that affect deployed Oracle products and software, with an emphasis on the ones that are critical for operation or house sensitive data. This will provide more benefits compared to working straight down the CPU list, spending resources remediating issues that could have no impact. Instead, make better informed decisions by adopting a risk-based approach.