Log4J Vulnerability

[Carl P.]

Hello,

We've been contacted by a client concerned about the Log4J vulnerability:

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
https://thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html
https://venturebeat.com/2021/12/10/the-log4j-vulnerability-is-bad-heres-the-good-news/

All of the above sites say that the problem is between 2.0-beta-9 and 2.14.1. The client is currently using Genero 2.41 which has a file in Report Writer called log4j-1.2.13.jar.

The client may be happy that the log4j is outside the version range that contains the vulnerability. But what if the client requires an update to the log4j 2.15.0 version that has been patched?

Thanks,

Carl

[Alex G.]

Hi,

Exactly, that version is not affected. That version has another security issue regarding server sockets (https://www.cvedetails.com/cve/CVE-2019-17571/) but GRE does not use the SocketServer executable so that this version it is not affected.

>But what if the client requires an update to the log4j 2.15.0 version that has been patched?

Why is the client requiring an update when the version is not affected?
Version 2 is not API compatible with version 1.x (see https://logging.apache.org/log4j/2.x/).
There is however a bridge jar (https://logging.apache.org/log4j/2.x/log4j-1.2-api/) that could be tried out (apparently if is sufficient to replace the log4j jar with the bridge jar and the 2.15.0 core jar). Quote from the above URL:

Usage
To use the Log4j Legacy Bridge just remove all the Log4j 1.x jars from the application and replace them with the bridge jar. Once in place all logging that uses Log4j 1.x will be routed to Log4j 2. However, applications that attempt to modify legacy Log4j by adding Appenders, Filters, etc may experience problems if they try to verify the success of these actions as these methods are largely no-ops

Best regards,
Alex

[Alex G.]

Hi,

just a small clarification to avoid a misunderstanding regarding my question of why the client is requiring the library to be updated, when it is not affected.
I am not questioning the request, I am just trying to understand.

Best regards,
Alex

[Carl P.]

Hi Alex,

My colleague had replied to the client this morning saying that our live and test servers at the client were not affected by this vulnerability. Then the client did a sweep of the servers, just in case and found the log4j Jar file in GRE. So we looked a little foolish. Also the client wanted to know our plan to patch the vulnerability.

I was asked if there was a way to update the log4j in the event that the client demanded that log4j used version 2.15.0.

Thanks for your help,

Carl

[Alex G.]

Hi Carl,

thanks for clarifying.
But your colleague was absolutely right :-). No, but seriously, they needn't worry. In this case we were lucky to not have updated to the latest version.
Should they get back then please contact our support and I will see to it that we try the bridge class and if that works, then they could go for that but again, it is not necessary.

Best regards,
Alex

[Reuben B.]

Hi Carl

Just to come back to something you said at the beginning ...

The client is currently using Genero 2.41 which has a file in Report Writer called log4j-1.2.13.jar.

The client may be happy that the log4j is outside the version range that contains the vulnerability. But what if the client requires an update to the log4j 2.15.0 version that has been patched?

As the current supported versions are Genero 4.00, 3.20, 3.10  as per our current plus two previous strategy, if hypothetically your client had required an update, they may have found that we only delivered maintenance releases for 3.10, 3.20 and 4.00.  If you look at Oliviers announcement https://forum.4js.com/fjs_forum/index.php?topic=1735.0 he references the three supported versions, if you look at the download products and download documentation page of our website, you will see the three supported versions.

Fortunately it has not happened in this instance but by continuing to use old versions you do face the possibility that an event such as this occurs, and you are left with the prospect of upgrading to a supported version of Genero at short notice.

Reuben

[Carl P.]

Alex,

A colleague has asked if the Genero Report Writer uses JMS Appenders?

https://www.veracode.com/blog/security-news/urgent-analysis-and-remediation-guidance-log4j-zero-day-rce-cve-2021-44228

> If you are using Log4j 1.x, you are impacted by this vulnerability only if you are using JMS Appenders. To verify if you are using this appender, double check your log4j configuration files for presence of org.apache.log4j.net.JMSAppender class.

[Alex G.]

Hi Carl,

No, we are not using the JMSAppender. The configurations are located in gre.jar in the resources directory and are named starting with the prefix "log4j_configuration" and can be inspected there ($JAVA_HOME/bin/jar -xvf $GREDIR/lib/jars/gre.jar).

Best regards,
Alex