Difference between revisions of "Apache Log4j & CMOD ODWEK ICN"
m (Converted CMOD version information to table.) |
(Minor updates to reflect ICN log4j vulnerability) |
||
| Line 39: | Line 39: | ||
== Impact == | == Impact == | ||
The largest impact is to systems that have publicly-facing IBM Content Navigator (ICN) installations, or line-of-business (LoB) apps (like client/customer portals) that rely on Log4j to provide logging. In most (reasonable) architectures, ODWEK itself is not exposed to the public internet, and instead, is used as an intermediate API between LoB applications that are internet-accessible and Content Manager OnDemand. In the overwhelming majority of | 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. | ||
'''Given that ODWEK is a niche API for a proprietary product, the risk to the data in a CMOD server is low.''' | '''Given that ODWEK is a niche API for a proprietary product, the risk to the data in a CMOD server is low.''' | ||
| Line 49: | Line 49: | ||
* CMOD with ICN or Line-of-Business apps exposed to the public internet with proper firewalls & access controls: ''Low to Medium'' | * CMOD with ICN or Line-of-Business apps exposed to the public internet with proper firewalls & access controls: ''Low to Medium'' | ||
* CMOD with ICN or Line-of-Business apps exposed to the public internet with unrestricted access to the CMOD server: ''High'' | * CMOD with ICN or Line-of-Business apps exposed to the public internet with unrestricted access to the CMOD server: ''High'' | ||
* CMOD and ODWEK running on the same server instance / operating system: ''Extreme'' | |||
== Upgrading log4j v2.15.x == | == Upgrading log4j v2.15.x == | ||
Revision as of 15:02, 11 December 2021
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 control of the affected servers.
Please upgrade as soon as possible, this vulnerability is being actively exploited on publicly facing systems. Download Link: Apache Log4j
This issue has been assigned the following designation: CVE-2021-44228
Announcements
Here are some announcements from trusted sources of information on software vulnerabilities:
https://logging.apache.org/log4j/2.x/security.html
https://cve.circl.lu/cve/CVE-2021-44228
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
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? |
|---|---|---|
| CMOD & ODWEK v9.0 | TBD | TBD |
| CMOD & ODWEK v9.5 | TBD | TBD |
| 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 |
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.
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:
- 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
- CMOD with ICN or Line-of-Business apps exposed to the public internet with proper firewalls & access controls: Low to Medium
- CMOD with ICN or Line-of-Business apps exposed to the public internet with unrestricted access to the CMOD server: High
- CMOD and ODWEK running on the same server instance / operating system: Extreme
Upgrading log4j v2.15.x
Download the latest version of Apache Log4j.
To install it, either:
- Replace the existing log4j*.jar file in your CMOD Directory (the defaults are /opt/IBM/ondemand/V10.x/jars or /opt/ibm/ondemand/V10.x/jars).
...or...
- Install the new library to a location of your choice, and add that location at the front of your CLASSPATH environment variable, so that it is found first in the search path.
Questions for IBM
Here are a few questions we've sent to IBM, and we'll update this article with their responses:
- Is log4j used for any purpose on a standalone CMOD server, or is it used exclusively for ODWEK?
- For ODWEK, in which situations/configurations would log4j be accessible to an API consumer?
- ICN v3 ships with Log4j 1.2.15, and is not included in this CVE due to being EOL'd earlier this year, so it's unknown if this version is affected. Is it possible top upgrade log4j to the patched version?
- For ICN, in which situations/configurations would log4j be accessible to an API consumer?
- Are their architectural mitigations that can be put in place? (Blocking firewall ports, specific URLs, changing the location of libraries, etc.)
- Will IBM provide an interim fix for this issue, or advise clients to patch log4j on their own?
If you have questions you'd like to see answered, find us on Twitter: https://Twitter.com/CMODwiki