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 22.214.171.124 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 126.96.36.199.
Java SE 8
EPM 188.8.131.52 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 # 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 3 months.
Oracle WebLogic / Fusion Middleware 184.108.40.206
(For my friends on the functional non-infrastructure side, here's 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 # for this is 30675853 and it is "WebLogic 220.127.116.11 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 18.104.22.168
(For my friends on the functional non-infrastructure side, here's 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 # for this is 30687404 and it is "Oracle HTTP Server 22.214.171.124 PSU 191219.2319" . This is also a cumulative patch and you also use OPatch to apply it.
(Update: Credit to "RJ" in the comments below who pointed out I had pasted an incorrect patch ID #. 30687404 is the correct patch ID # to use as of this writing)
The "-oh" parameter you pass to \Oracle\Middleware\ohs\OPatch\opatch.bat is \Oracle\Middleware\ohs
Oracle EPM / Hyperion 126.96.36.199
No references to EPM 11.2 in JAN2020CPU as mentioned earlier.
Essbase Suite 188.8.131.52
No references to Oracle Essbase/APS/EAS 184.108.40.206 in JAN2020CPU. There is a separate Oracle Inventory on your EPM 11.2 server(s) for Essbase Suite 220.127.116.11, 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 18.104.22.168 where Essbase Suite 22.214.171.124 is concerned:
|29260139||Essbase Studio Server 126.96.36.199.031|
|29260160||Essbase Admin Server 188.8.131.52.031|
|29749671||Analytic Provider Services 184.108.40.206.033|
|29749652||Essbase RTC 220.127.116.11.033|
|29749662||Essbase Server 18.104.22.168.033|
Oracle Data Integrator 22.214.171.124
ODI 126.96.36.199 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 # is 29778645 for "ODI BUNDLE PATCH 188.8.131.52.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 184.108.40.206. 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 220.127.116.11 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 18.104.22.168 or 22.214.171.124 -- those use WebLogic 10.3.6. EPM 126.96.36.199 uses WebLogic 188.8.131.52.
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 my caffeine than it took you to get all the way to this paragraph!
You can mitigate any panic by explaining 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.