January 2020 Oracle Critical Patch Update Affects EPM 11.2

So you’ve spun up your shiny new Hyperion/Oracle EPM 11.2.0.0. And now… it is time to patch!

I haven’t come across a comprehensive patching guide for EPM 11.2 yet, so here’s my attempt to create one. This guide assumes you’ve patched EPM 11.1.x.x in the past and are familiar with Oracle’s “OPatch” utility.

As usual, assume you will take an outage and shut down the EPM stack across all servers before patching (one environment at a time, please!! “Gee Dave, what could possibly go wrong?”).

Oracle’s quarterly “Critical Patch Update” (CPU for short) was published in mid-January 2020 right on schedule. As expected, there are impacts to EPM 11.2, even though EPM 11.2.0.0 isn’t mentioned by name.

For your reference, there’s a link to Oracle’s JAN2020CPU (as they call it) announcement:
Oracle JAN2020CPU Security Alert

In a nutshell, here’s what is believed to apply to EPM 11.2.0.0.

Java SE 8

EPM 11.2.0.0 ships with Java SE 1.8 Update 181. This is “old” as it apparently was published in the APR2019CPU, and Java has been updated every quarter since then. The version we should use as of January 2020 is Java SE 1.8 Update 241.

The patch # for Java SE 8 is 18143322 and you should hop into support.oracle.com and bookmark that patch. Oracle will re-use this patch number every time a new Java 8 patch is issued. Make your patch search screen look like this so you can find it quickly:

 
This is not a “patch”; it is a full install. You can install it on just one server’s C: drive, deselect the ‘public JRE’ option within the install wizard, and accept the other default prompts. When finished, copy it to your D/E/F drive as appropriate to your various Hyperion servers and save it as \Oracle\Middleware\jdk8.

Once you’ve finished this task, you can uninstall it via the Windows Control Panel from the C: drive on the one server you installed it to.

You will then face a decision that is worthy of a separate blog post: Do you replace the content of \Oracle\Middleware\jdk1.8.0_181, or do you update the Windows Registry and various bat/cmd files to replace all references of jdk1.8.0_181 to jdk8? Replacing the content of the jdk1.8.0_181 folder is the fastest and easiest solution by far… until somebody in IT notices and asks why a vulnerable version of Java is installed.

Before you decide right away, remember Java 8 will likely be updated by Oracle every three months.

Oracle WebLogic/Fusion Middleware 12.2.1.3

For my friends on the functional non-infrastructure side, this section covers “why you care.” Hyperion does not function without WebLogic/FMW running behind the scenes. When you start up web services like EPM Foundation, Planning Web, HFM Web, EAS Server, etc, you are starting an ‘Oracle WebLogic Managed Server.’ When WEbLogic/FMW has a security vulnerability, then you should consider your EPM system to be equally vulnerable.

The patch number for this is #30675853 and it is ‘WebLogic 12.2.1.3 PSU 191217.1425.’ This is a cumulative patch.

The very good news is we no longer need to use the BEA Smart Update (bsu.bat) utility! In fact, that entire directory structure doesn’t exist anymore. We now use good ol’ Oracle OPatch.

The ‘-oh’ parameter you pass to \Oracle\Middleware\OPatch\opatch.bat is \Oracle\Middleware.

In addition to updating Oracle WebLogic, it also updates some files within the \Oracle\Middleware\oracle_common directory hierarchy (Oracle ADF / JDeveloper and the like).

Oracle HTTP Server 12.2.1.3

For my friends on the functional non-infrastructure side, this section is “why you care.” OHS is the front-end proxy for EPM Workspace. This is what listens to port 19000/19443. As stated in the WebLogic section above, if OHS can be exploited, then so too can your EPM system.

The patch number for this is #25115951 and it is ‘Oracle HTTP Server 12.2.1.3 PSU 191219.2319.’ This is also a cumulative patch and you also use OPatch to apply it.

The ‘-oh’ parameter you pass to \Oracle\Middleware\ohs\OPatch\opatch.bat is \Oracle\Middleware\ohs.

Oracle EPM / Hyperion 11.2.0.0

There are no references to EPM 11.2 in JAN2020CPU, as mentioned earlier.

Essbase Suite 11.1.2.4

There are also no references to Oracle Essbase/APS/EAS 11.1.2.4 in JAN2020CPU. There is a separate Oracle Inventory on your EPM 11.2 server(s) for Essbase Suite 11.1.2.4, if installed, so you can still patch it if you want some of the newer Essbase-related bugfixes.

Here’s what you have out of the box in EPM 11.2.0.0 where Essbase Suite 11.1.2.4 is concerned:

Oracle Data Integrator 12.2.1.3

ODI 12.2.1.3 is referenced within JAN2020CPU, but I’d avoid it for now until more information is forthcoming. If you want to take a look, the patch number is #29778645 for ‘ODI BUNDLE PATCH 12.2.1.3.190708 (CPU).’ This patch updates the ODI Studio thick client, which expects some minor tweaks to ODI’s Master repository.

You can apply this patch if your ODI is standalone and is NOT the one bundled with FDMEE 11.2.0.0. This is because the patch wants you to run the Oracle Upgrade Assistant utility, which expects that the ODI Master and Work repositories were built through the Repository Creation Utility (‘RCU’) rather than by the EPM System Configuration tool when you ran the ‘Configure Database’ step for FDMEE.

We will likely need to wait for an FDMEE 11.2.0.0 patch, which I’d expect to include a new *.drv file that instructs FDMEE to update the ODI repository when FDMEE is restarted.

Clear As Mud???

One question I’m asked by customer IT departments from time to time:  “Do we really need to do this?”

Here’s one way to answer IT’s question: Forward Oracle’s JAN2020CPU advisory article, linked at the top of this blog entry. Here’s just one specific example from the article:

 
I highlighted in red some, but not all, of the important nuggets of information:

• CVE#. IT can paste into their favorite Internet search engine to learn more.
• Product.  Oracle WebLogic Server is the technology behind pretty much all of Hyperion’s web services in 11.2, except for DRM.
• Remote Exploit without Auth.  A “yes” means an attacker doesn’t need a userID/password for the server or application in order to cause mischief.
• Base Score.  This is on a scale of 1 to 10, with 10 being the most serious.
• Supported Versions Affected.  I highlighted 10.3.6 for our friends who are still on EPM 11.1.2.3 or 11.1.2.4 — those use WebLogic 10.3.6.  EPM 11.2.0.0 uses WebLogic 12.2.1.3.

Give this example to your IT counterpart, along with the link to Oracle’s advisory article, and ask if IT is willing to live with the scores listed throughout the article (again, the above is just one example, but there are many ranging from the low 4s to the high 8s and 9s).

Be mindful the JAN2020CPU advisory mentions everything Oracle; Oracle Database, MySQL, Java, Hyperion, Oracle Financials, etc. This makes reading through the entire advisory a daunting task. I advise doing so only after ingesting the caffeine that it took you to get all the way to this paragraph!

You can mitigate any panic by explaining that the on-premises Oracle EPM system typically sits behind a corporate firewall and is not exposed to the public Internet. By applying these various patches, you are mitigating risk of a disgruntled employee wanting to cause mischief or steal data before their last day.