I can still remember the surprise when Frits Hoogland pointed out that Oracle had replaced the old OC4J instance on Exadata storage servers with a WebLogic service. I wasn’t quite sure what to make of this, but it’s become apparent as things move cloudward that it would enable an entire set of REST operations for Exadata on both storage and compute tiers. This becomes interesting due to the recent 0-day vulnerability for WebLogic, CVE-2019-2725. According to Oracle’s security advisory, CVE-2019-2725 is “remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password.” In other words, it’s particularly nasty. With Exadata now running a WebLogic instance for the management server, this bug opens customers up to this vulnerability. This vulnerability applies to both WebLogic 10.3.6 and 12.1.3 - Exadata systems running image version 12.x and 18.x are using the 10.3.6 version of WebLogic. Early adopters running the 19.x Exadata image can be happy to know that they aren’t susceptible to this issue, as it uses WebLogic 12.2.
Since the vulnerability was published after the April 2019 patches were issued, this causes an issue for the patch release cycle. At the time of this writing, Oracle has re-released the April 2019 Exadata image patches (19.2.1.0.0 and 18.1.15.0.0) with versions that include the fixes for this vulnerability, as well as a another storage server bug. The quarterly full stack patch has been pulled, and is expected to be reissued soon.
But, what if you haven't applied the April patches yet and need this fix? Oracle has released a support note (2539001.1) with links to patches for some earlier versions of the software. I’ll be looking at the 18.1.14.0.0 fix, since we have a copy running in the Enkitec lab.
This vulnerability affects both the storage servers and compute nodes, and has different installation methods. The patch download contains fixes for both.
For the compute nodes, you will need to apply an updated RPM package that contains a patched version of WebLogic.
# rpm -Uvh exadata-dbmmgmt-18.1.14.0.0.190511-1.noarch.rpm
# dbmcli -e alter dbserver restart services allFor the storage servers, the patch includes both a full image as well as an RPM package that includes the fix. If you want to install a new full image of the cell, use the files in cell/patch_<VERSION> to run the standard storage server update process (patchmgr). If you just want to update the WebLogic component, then you can update just the cell RPM file found in cell/RPM_patch_<VERSION>. Be sure to check that grid disks can be safely taken offline before patching, and always wait for all disks to be back online before moving to the next cell when rolling your patches. The process to apply the oneoff RPM patch to 18.1.14.0.0 is:
# cellcli -e list griddisk attributes name,status,asmmodestatus,asmdeactivationoutcome where asmdeactivationoutcome != yes
# rpm -qa | grep ^cell-
cell-18.1.14.0.0_LINUX.X64_190320-1.x86_64
# cellcli -e alter griddisk all inactive
# cellcli -e list griddisk attributes name,status,asmmodestatus,asmdeactivationoutcome where asmmodestatus != OFFLINE
# /tmp/cell-18.1.14.0.0.29760300V1_LINUX.X64_190511-1-rpm.bin --doall --force
Performing pre-install checks for installing this one-off rpm..
[INFO] Installing cell software:
[INFO] Upgrade from version cell-18.1.14.0.0_LINUX.X64_190320-1.x86_64 to version cell-18.1.14.0.0.29760300V1_LINUX.X64_190511-1.x86_64
Preparing... ########################################### [100%]
1:cell ########################################### [100%]
#########################################################
Logout and then re-login to use the new cell environment.
#########################################################
[INFO] Upgrade was successful.
# cellcli -e list cell attributes cellsrvStatus,msStatus,rsStatus
# cellcli -e alter griddisk all active
# cellcli -e list griddisk attributes name,asmmodestatus where asmmodestatus != ONLINE