Just an FYI Apache seems to be recommending that this will not completely remediate the vulnerability.
https://logging.apache.org/log4j/2.x/security.html
History
Older (discredited) mitigation measures
This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open.
Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.
------------------------------
aaron robertson
------------------------------
Original Message:
Sent: Tue December 14, 2021 05:38 AM
From: Marcel van der Heide
Subject: Maximo vs Log4Shell vulnerability
I have the same feeling as Arun is raising here. When we use Installation Manager to update Websphere, it will update to version 9.0.5.10 and also include the hotfix42728 to your system.
When i do a search on Log4j in the IBM folder structure, I see that the Websphere ones are update to the recommended 2.15.0 but the Maximo ones are on 1.2.16 or 1.2.17. (this is maximo 7.6.1.2).
I think it would help everyone to understand the version numbering if the Maximo versions are not vulnerable.
------------------------------
Marcel van der Heide
Original Message:
Sent: Mon December 13, 2021 05:07 AM
From: Arun
Subject: Maximo vs Log4Shell vulnerability
Thanks for the inputs Diego. I would be relieved to see any IBM article that officially backs this recommendation as reading some of the articles about this CVE, Apache seems to have patched the issue in log4j V 2.15.0 and the recommendation is to upgrade to this latest version.
Maximo's version of 1.2.x is very old and was released way back in 2010.
------------------------------
AK
Original Message:
Sent: Mon December 13, 2021 04:09 AM
From: Diego Visentin
Subject: Maximo vs Log4Shell vulnerability
Maximo uses Log4J for logging (see Maximo Asset Management Logging (ibm.com))
In an updated version like 7.6.1.2, it uses a version of the library (c:\IBM\SMP\maximo\applications\maximo\lib\log4j-1.2.16.jar) that it's not affected by this mess. Instead, the older versions seem to have also included the 2.x version of the library. in this case you must decide what to do. One suggestion is to set the property that disables the vulnerable feature. Others suggest removing that code from the distributed library.
------------------------------
Diego Visentin
EAM BU Director
Tempestive S.p.A.
Pordenone
Original Message:
Sent: Mon December 13, 2021 02:09 AM
From: Klaus Schmidinger
Subject: Maximo vs Log4Shell vulnerability
is maximo using log4j somewhere? The files I've found in SMP (ibm control desk 7.6.1.4) are using log4j v1.x
I've found v2 it within ISCLITE (WebSphere v9), and IBM already provided a fix to update log4j2. (9.0.5.3-ws-wasprod-ifph42728)
"Old" environments (WebSphere 8.5.x) seem to use log4j1 which should not be affected?
Original Message:
Sent: Sun December 12, 2021 10:05 AM
From: Diego Visentin
Subject: Maximo vs Log4Shell vulnerability
An updated Maximo should have no problems with the CVE-2021-44228 vulnerability (aka Log4Shell) because system property "com.sun.jndi.ldap.object.trustURLCodebase" should be false by default (check the Java version to be sure).
However, if you are in doubt or your env is old, you can add the "log4j2.formatMsgNoLookups" param to mitigate this critical issue.
------------------------------
Diego Visentin
EAM BU Director
Tempestive S.p.A.
Pordenone
------------------------------
#AssetandFacilitiesManagement
#Maximo