Fresh update about SC here: portal.microfocus.com/.../KM000003049

Update about SC here: portal.microfocus.com/.../KM000003049

How does the new CVE - CVE-2021-45046 (mitre.org) factor into the formatMsgNoLookups=true recommendation? 

The mitigation for .15 is incomplete and there's already a new CVE:

CVE-2021-45046
https://www.cve.org/CVERecord?id=CVE-2021-45046

MF needs to update their advisory 
https://portal.microfocus.com/s/article/KM000003049?language=en_US

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability.

Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

So I did wonder why they went the whole hog and removed the class from ESM but not the Smartconn.

Maybe log4j is used within it , maybe it was felt this was easier to implement for us . 

I guess we all need a quick anser to that . We asked the question in our original ticket , can we just remove the class and got no response

Hearing mitigation for SmartConnector may does not address the log4j issue:

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.

Also Log4j 2.16.0 was released to fix a subsequent cve

For those who haven't seen, there is now a hotfix for ESM you should see this in your download portal with names like "ESM 7.5 Patch for CVE-2021-44228" other products to follow, the connector recommendation has now also changed to updating log4j to 2.16 as well as updated guidance for most products.

@vitz1 - please contact my colleague @Eknappen for anything security related in the future. I changed jobs and I am no longer part of security. Thank you!

They updated the KM articles but beware the smartcon on the fly update script is bugged

It assumes all smartconns under the point you run it are 8.2.x and forces in the 2.16 class regardless

It searches for the impacted class and removes it . I don't know what it will do to another version SC that hasn't got the libs

They rewrite the classpath and a few other things . I think its just going to put the 2.16 class down in the tree and try to fix classpaths (which will fail)

It just feels messy and they still list setting the parameter as option A which feels wrong .

It seems crazy that they are doing different things for each product . What we need is a 8.2 Psomething framework update we can send out from ArcMc and know its tested and correct 

alunj

1. Connector’s KB has (had) guidance to add a JVM parameter, but not modifying the jar files. This is N/A for Connectors.