webMethods

What product/components do you use and which version/fix level?

EntireX Web Services Stack 10.5.0.0.448

Are you using a free trial or a product with a customer license?

Licensed

What are trying to achieve? Please describe in detail.

Address alert for log4j security vulnerability CVE-2021-44228.

Do you get any error messages? Please provide a full error message screenshot and log file.

No

I am looking to address the log4j vulnerability CVE-2021-44228, and it appears there is use of log4j in the WS-Stack under the /webapps/wsstack/WEB-INF/lib path. I have downloaded log4j 2.16.0 from Apache’s website and am wondering… if I replace the log4j files that path with their newer versions, repackage wsstack.war and redeploy it (Kintana war file deployment), will that work and be a supported fix?

R&D strongly discouraged my thoughts here but I am unclear now how to apply the recommendation of setting log4j2.formatMsgNoLookups = true in the context of the supplied log4j 2.11.2 that came with EntireX 10.5. I am thinking this is done via the log4j.properties file that is found in the \webapp\wsstack\WEB-INF\classes path, but it is unclear to me what the actual parameter name is here, or even if what I inferred is correct (that this is where I set this to mitigate the security risk under this version of log4j).

Can someone please advise, as this is not really covered on the official document published by Software AG for this issue.

Please check if the bundled log4j jar is a version 1 or version 2 jar and its exact build version.

The best way to do is to locate the bundled log4j jar (in most cases under common/lib/ext) and extract its META-INF/MANIFEST.MF.
This one should contain the neccessary informations about the concrete log4j version.
In Empower you will find an according documentation how to mitigate this issue.

Might be that EntireX is still using log4j version 1 which is not affected.

Regards,
Holger

Hi Holger,

The jar files (in \webapp\wsstack\WEB-INF\lib) reference version 2.11.2 (e.g., log4j-core-2.11.2.jar). MANIFEST.MF doesn’t list log4j:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 25.181-b13 (Oracle Corporation)
Built-By: Software AG
Build-Jdk: 1.8.0_181
Build-Date: 2021-03-12 03:36:45
Build-Number: 448
SVN-Revision: 8592084
Implementation-Title: wsstack-war
Implementation-Description: WebServices-Stack war distribution
Implementation-Version: 10.5.0.0
Implementation-Vendor: Software AG

What I am inclined to do is change the log4j.properties file and add a line like this:
log4j2.formatMsgNoLookups = true

However, is that valid here? None of the existing entries in log4j.properties starts with log4j2 dot anything. The first qualifier is either appender, logger or rootLogger for all entries.

Brian,

this is not a properties file option but rather a system property of the form

-Dlog4j2.formatMsgNoLookups=true

The suggested solution at the properties file level is to replace all occurrences of %m with %m{nolookups} in every pattern.

I found the right MANIFEST.MF file, and it confirms:
Specification-Version: 2.11.2
Log4jReleaseVersion: 2.11.2

Poking around the 'Net, I see a recommendation to just remove the JndiLookup class from the log4j-core-2.11.2.jar file, but I am not finding yet. I drilled down to org\apache\logging\log4j\core\ and am exploring the subdirectories.

Doing “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class” did nothing.

Duh… just saw that it was just down in the lookup folder. I assume if I just remove JndiLookup.class from here all will be protected from this vulnerability.

Can anyone confirm this, please?

Based on all we know today - yes.

In case you run multiple instances or applications that include log4j and don’t want to update all of them individually (and probably miss one or two) an easier option might be to set the environment variable
LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Thanks much, Wolfgang! It is much appreciated.

I wanted to throw an update out here as things have evolved. Software AG will be providing a fix for the Web Service Stack that includes log4j v2.16.0. Other suggestions have not fully protected against the vulnerability though they do mitigate some of the threat but leave some attack vectors open. Additionally, log4j v2.15.0 only went part way in addressing the issue and is not recommended (see Incomplete fix for Apache Log4j vulnerability · CVE-2021-45046 · GitHub Advisory Database · GitHub). From Support, the official recommended action is to apply this WS-Stack update ASAP, though it is possible if you know what you’re doing, I suppose, to upgrade the log4j components yourself to v2.16.0 and achieve desired results.