VMS Software has posted a bulletin about the recent Apache Log4j2 V2.14.1 (or earlier) vulnerability (CVE-2021-44228) as it affects #OpenVMS systems, including remediation for VSI-provided software components.

The full notice can be retrieved from: https://vmssoftware.com/about/news/2021-12-14-cve-2021-44228-comments/ #Log4j2

- Bob Gezelter, http://www.rlgsc.com

On 2021-12-15 16:17:04 +0000, Bob Gezelter said:

> VMS Software has posted a bulletin about the recent Apache Log4j2
> V2.14.1 (or earlier) vulnerability (CVE-2021-44228) as it affects
> #OpenVMS systems, including remediation for VSI-provided software
> components.
>
> The full notice can be retrieved from:
> https://vmssoftware.com/about/news/2021-12-14-cve-2021-44228-comments/

The zip command shown is twice wrong unfortunately, the mitigations
other than zip or patching to current are no longer being recommended
AFAICT, and the VSI bulletin is unfortunately missing mention of the
CVE-2021-45046 and CVE-2021-4104 vulnerabilities.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104

That the VSI bulletin doesn't mention the HPE 3PAR and XP
vulnerabilities is certainly understandable in some ways, but is also
less than helpful in others.

Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
affected and either need to be zip-mitigated, or needs to be updated as
that becomes available, based on that notice, too.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/15/21 6:11 PM, Stephen Hoffman wrote:

> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
> affected and either need to be zip-mitigated, or needs to be updated as
> that becomes available, based on that notice, too.

As far as I know, VSI and HPE Tomcat, aka CSWS_JAVA, are based on Apache
Tomcat and the latter is not affected:
https://cwiki.apache.org/confluence/display/TOMCAT/Security#Security-Q13.

Whether applications deployed to Tomcat use log4j2 is a different question.

On 12/15/21 11:11 AM, Stephen Hoffman wrote:

> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
> affected and either need to be zip-mitigated, or needs to be updated as
> that becomes available, based on that notice, too.

Does the zip mitigation (deleting a class from a JAR) work on signed jar
files? I would have thought not since I would expect changing any
contents of a signed jar file would invalidate the signature. Which
means waiting for the signer, in many cases a third party, to fix their
code and re-sign it. Or seek other mitigations.

On 12/15/2021 1:13 PM, Craig A. Berry wrote:
> On 12/15/21 11:11 AM, Stephen Hoffman wrote:
>> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
>> affected and either need to be zip-mitigated, or needs to be updated
>> as that becomes available, based on that notice, too.
>
> Does the zip mitigation (deleting a class from a JAR) work on signed jar
> files?  I would have thought not since I would expect changing any
> contents of a signed jar file would invalidate the signature.

Changing the jar file will obviously invalidate the signature.

But as far as I can see then log4j jars are not signed.

Arne

On 2021-12-15 17:52:25 +0000, hb said:

> On 12/15/21 6:11 PM, Stephen Hoffman wrote:
>
>> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
>> affected and either need to be zip-mitigated, or needs to be updated as
>> that becomes available, based on that notice, too.
>
> As far as I know, VSI and HPE Tomcat, aka CSWS_JAVA, are based on Apache
> Tomcat and the latter is not affected:
> https://cwiki.apache.org/confluence/display/TOMCAT/Security#Security-Q13.
>
> Whether applications deployed to Tomcat use log4j2 is a different question.

Okay. Sure. Tomcat itself is not vulnerable. Alas, approximately nobody
uses that configuration. Which means that apps using Tomcat will have
to be checked. Which usually means zip mitigation, or updates.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/15/2021 12:11 PM, Stephen Hoffman wrote:
> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
> affected and either need to be zip-mitigated, or needs to be updated as
> that becomes available, based on that notice, too.

Neither HPE nor VSI Java comes with log4j. Java itself does not log
at all- it just provide its own logging framework for use.

Neither HPE nor VSI Tomcat comes with log4j. Tomcat use
java.util.logging aka jul aka jdk14 logging (in a customized flavor
called juli).

So they do not as product have the vulnerability and cannot
be fixed by updating.

But a Tomcat installation may very well have the vulnerability.

Nobody install Tomcat to just run Tomcat. Tomcat is installed to
run Java web application. And those web applications may use log4j.
And that applies to both third part Java web applications and
to home grown Java web applications.

So people should check.

A clean Tomcat install does not have any log4j in lib dir, but
log4j could have been put there after installation (to make it
available for all web apps instead of having to deploy it for each).

And every web app could have it - after war unpack it will be in
webapps/something/WEB-INF/lib.

And as stated previously look out for fatjars as well!

But that is not HPE/VSI responsibility - that is third party/home grower
responsibility.

Arne

On 12/15/21 12:28 PM, Stephen Hoffman wrote:
> On 2021-12-15 17:52:25 +0000, hb said:
>
>> On 12/15/21 6:11 PM, Stephen Hoffman wrote:
>>
>>> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
>>> affected and either need to be zip-mitigated, or needs to be updated as
>>> that becomes available, based on that notice, too.
>>
>> As far as I know, VSI and HPE Tomcat, aka CSWS_JAVA, are based on Apache
>> Tomcat and the latter is not affected:
>> https://cwiki.apache.org/confluence/display/TOMCAT/Security#Security-Q13.
>>
>> Whether applications deployed to Tomcat use log4j2 is a different
>> question.
>
> Okay. Sure. Tomcat itself is not vulnerable. Alas, approximately nobody
> uses that configuration. Which means that apps using Tomcat will have to
> be checked. Which usually means zip mitigation, or updates.

Or changes to the configuration to prevent lookups, which can sometimes
be done my a simple replacement in the configuration file:

perl -pi -e 's/\%m\b/%m{noLookups}/g;' log4j2.xml

or by tweaking various environment variables to do the equivalent. But
just as a finger in the dike until an updated log4j can be incorporated
into the relevant package.

On 12/15/21 12:24 PM, Arne Vajhøj wrote:
> On 12/15/2021 1:13 PM, Craig A. Berry wrote:
>> On 12/15/21 11:11 AM, Stephen Hoffman wrote:
>>> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
>>> affected and either need to be zip-mitigated, or needs to be updated
>>> as that becomes available, based on that notice, too.
>>
>> Does the zip mitigation (deleting a class from a JAR) work on signed jar
>> files?  I would have thought not since I would expect changing any
>> contents of a signed jar file would invalidate the signature.
>
> Changing the jar file will obviously invalidate the signature.
>
> But as far as I can see then log4j jars are not signed.

The application packager, not the library developer, has to do the
signing. So, for example, OpenWebStart apps have to sign all the
downloadable jars with the same code-signing certificate.

On 12/15/2021 1:49 PM, Craig A. Berry wrote:
> On 12/15/21 12:24 PM, Arne Vajhøj wrote:
>> On 12/15/2021 1:13 PM, Craig A. Berry wrote:
>>> On 12/15/21 11:11 AM, Stephen Hoffman wrote:
>>>> Seems that VSI and HPE Java distributions and VSI and HPE Tomcat are
>>>> affected and either need to be zip-mitigated, or needs to be updated
>>>> as that becomes available, based on that notice, too.
>>>
>>> Does the zip mitigation (deleting a class from a JAR) work on signed jar
>>> files?  I would have thought not since I would expect changing any
>>> contents of a signed jar file would invalidate the signature.
>>
>> Changing the jar file will obviously invalidate the signature.
>>
>> But as far as I can see then log4j jars are not signed.
>
> The application packager, not the library developer, has to do the
> signing.  So, for example, OpenWebStart apps have to sign all the
> downloadable jars with the same code-signing certificate.

In that case you will need to have that signer sign the modified
version.

I know very little about Java Web Start, but I would have thought that
it ran with a security manager preventing both access to remote
systems and local access.

Arne

On 12/15/2021 11:17 AM, Bob Gezelter wrote:
> VMS Software has posted a bulletin about the recent Apache Log4j2
> V2.14.1 (or earlier) vulnerability (CVE-2021-44228) as it affects
> #OpenVMS systems, including remediation for VSI-provided software
> components.
>
>
> The full notice can be retrieved from:
> https://vmssoftware.com/about/news/2021-12-14-cve-2021-44228-comments/
> #Log4j2

They basically say that Tomcat and Kafka client does not use log4j.

And that Axis2 and ActiveMQ use log4j 1.x, which in general is not
good but in relation to this particular problem is good.

And refer a few third party products to third party.

But It is worth noting that this is the easy part.

There are only a few hundreds/thousands "platform products"
using log4j - vendors create patches - customers hopefully
install.

A much bigger problem is those hundreds of thousands/millions
of business applications using log4j from thousands/tens of thousands
of vendors. Just due to the numbers some will be missed.

And then there is the problem of "thingys" having a Java
application using log4j insider. Many people will not be
aware that they run Java. And they can be difficult to
update.

Arne

> perl -pi -e 's/\%m\b/%m{noLookups}/g;' log4j2.xml

In examining config files in my apps, I saw things like

%-1000m{...}

so I think this perl snippet will be an incomplete fix.

De

On 12/15/21 1:34 PM, Dennis Boone wrote:
> > perl -pi -e 's/\%m\b/%m{noLookups}/g;' log4j2.xml
>
> In examining config files in my apps, I saw things like
>
> %-1000m{...}
>
> so I think this perl snippet will be an incomplete fix.

Thanks for pointing that out. It worked for the one simple case I
needed to deal with, but it doesn't surprise me you'd need a better
regex for other cases.