Apache Log4j & CMOD ODWEK ICN

This article discusses IBM Content Manager OnDemand (CMOD), the OnDemand Web Enablement Kit (ODWEK), IBM Content Navigator (ICN) and the Apache Log4j library, for which a Remote Code Execution (RCE) vulnerability is actively being exploited, which can give attackers elevated access, or effective control of the affected servers.

This issue has been assigned the following designation: CVE-2021-44228 and scores a 10 out of 10 on the Common Vulnerability Scoring System (CVSS)

UPDATE: IBM has responded to a customer ticket, stating that CMOD / ODWEK do not use the JNDI feature of log4j, and *should* not be vulnerable, but still advises customers to upgrade.

Follow the upgrade instructions here: Upgrading log4j

Announcements

Here are some announcements from trusted sources of information on software vulnerabilities:

IBM's X-Force assessment of log4j bug

Announcement of the issue on the developer website

National Institute of Standards and Technology

Discussion of log4j v1.x susceptibility to this exploit on GitHub

Affected Versions of Log4j

Versions from v2.0 beta9 through 2.14.x are vulnerable to this exploit.

The version that includes the fix is v2.15.x and above, released December 10th, 2021.

Versions Shipped with CMOD

CMOD Version	Apache Log4j version(s)	Vulnerable version?
CMOD & ODWEK v9.0	N/A	NO
CMOD & ODWEK v9.5	N/A	NO
CMOD & ODWEK v10.1	v2.6.x	YES
CMOD & ODWEK v10.5	v2.13.x	YES
ICN v2.0.3	TBD	TBD
ICN v3	v1.2.x	NO

ICN v3 is not vulnerable in the default configuration, but sites that have enabled the JMSAppender feature could be exploited.

Impact

The largest impact is to systems that have publicly-facing IBM Content Navigator (ICN) installations where the ODWEK Java API is also publicly accessible, or line-of-business (LoB) apps (like client/customer portals) that rely on Log4j to provide logging. In most (reasonable) system architectures, ODWEK itself is not exposed to the public internet, and instead, is used as an intermediate API (typically install a network DMZ) between LoB applications that are internet-accessible and Content Manager OnDemand. In the overwhelming majority of system designs, there are firewalls and other access controls on both the external and internal sides of a web server. However, if an attacker was able to obtain an elevated level of access to a web server, they may be able to use that elevated access to attempt to exploit ODWEK.

Which CMOD components use Apache log4j?

The three components that use the log4j library are the ODWEK Java API, the REST API (new in CMOD v10.5) and the Full Text Search engine.

How does ODWEK Java API / REST API / FTS use the log4j library?

They are referenced through a classloader.

Is a standalone CMOD server (without IBM HTTP / Websphere / ODWEK / REST API / FTS configured) vulnerable?

No, CMOD itself does not call or use log4j.

Where do I need to install the new version of the Apache log4j library?

Anywhere that you have installed CMOD - this includes: all CMOD servers, WebSphere/Tomcat/HTTP servers with CMOD, ODWEK, or the REST API components, and development servers for line-of-business applications that use ODWEK/REST APIs.

Given that ODWEK is a niche API for a proprietary product, the risk to the data in a CMOD server is low.

Here are a list of scenarios, and the likely level of risk to this vulnerability: (Last updated Dec 13th, 10am)

• An organization with CMOD on their internal network using Windows 'Thick' Clients: Very Low
• CMOD and IBM Content Navigator or Line-of-Business apps that reply on ODWEK: Low
• Line-of-Business apps using CMOD that are exposed to the public internet with proper firewalls & access controls: Low
• Line-of-Business apps using CMOD that are exposed to the public internet with unrestricted access to the CMOD server: Low
• CMOD and ODWEK running on the same server instance / operating system & accessible to the internet: Medium

Upgrading log4j v2.15.x

IBM has begun replying to customer tickets with this information:

 CMOD Lab is aware of the log4j vulnerability. See the below from the development.
 
 "neither the ODWEK nor the REST API’s use the JNDI feature of LOG4J which is at the core of the security vulnerability recently discovered. However, to be safe, it is recommended you upgrade to Log4j 2.15.0."
 
 Follow the instructions below to upgrade the OnDemand REST services or ODWEK based applications that are leveraging log4j.
 
 Go to https://downloads.apache.org/logging/log4j/2.15.0/ and select the file for your OS to download.
 
 E.g., apache-log4j-2.15.0-bin.zip for windows, apache-log4j-2.15.0-tar.gz for Unix.
 
 Once you extract the downloaded file, you should have a folder with a several files, including log4j-api-2.15.0.jar and log4j-core-2.15.0.jar. These are the only two files used by the OnDemand Web Enablement Kit and the REST API’s
 
 Use them to replace the following:
 
 <OnDemand Install Directory>/jars/log4j-api-2.13.0.jar
 <OnDemand Install Directory>/jars/log4j-core-2.13.0.jar
 
 You will need to stop any applications that use these files prior to replacing them. Delete the original 2.13.0 files. Place the log4j-api-2.15.0.jar and log4j-core-2.15.0.jar files into the directory that contained the deleted files. You will then need to update the classpath within your application server to reference the new version of these files. This is true for both ODWEK applications that use LOG4J and the OnDemand REST services. Once the classpath has been updated you can restart your applications"

Questions & Responses

If you have questions you'd like to see answered, find us on Twitter: https://Twitter.com/CMODwiki

Discuss on LinkedIn: https://www.linkedin.com/posts/justinderrick_apache-log4j-cmod-odwek-icn-activity-6875483828106932224-ledY

Discuss on the Content Manager OnDemand User Group Forums: http://www.odusergroup.org/forums/index.php/topic,3221.0.html