Remove Log4j1 from Papyrus. Replace with Log4j2

[emammoser]

Issue and tracking information

Developer's time Estimated effort to fix (hours):

Developer's Actual time spent on fix (hours)

Issue reporter to provide a detailed description of the issue in the space below

We have an urgent need to have log4j1 removed from our development environments and we noticed that it is packaged along with papyrus. We would like this removed and replaced with log4j2 which does not have the security vulnerabilities that log4j1 has.

[eposse]

I imagine you'll want me to work on this and put #450 on hold until this is resolved, right?

[emammoser]

Yes, I sent you email regarding this, but maybe it didn't go through. Unfortunately, our team wasn't given a lot of heads up that this was an urgent matter. We appreciate your flexibility

[eposse]

I have been doing a preliminary investigation of this issue, and here are some facts and information I've found.

First, I wanted to make a distinction between (plain) Papyrus and Papyrus CX. We develop the later, not the former. So any problems with (plain) Papyrus are more difficult to solve because we do not control it. Since we are still based on an older version (4.8 2020-06), if something needs to be changed, we can only do feature patches. And this usually is more difficult than just updating our own plugins.

So with that in mind, I started to look into a (plain) Papyrus install to see if it contains the problematic bundle.

Plain Papyrus contains the following:

    Eclipse Orbit   Apache Jakarta log4j Plug-in    1.2.15.v201012070815    org.apache.log4j

Papyrus CX contains, in addition to the above, this one:

    Eclipse Xtext   Xtext Log4J Fragment    1.2.15.v20200602-1242   org.eclipse.xtext.logging

I also found the following, very important message on the Eclipse forums, addressing the vulnerability and this particular version of org.apache.log4j:

Re: Is org.apache.log4j_1.2.15 impacted by critical CVE-2021-44228

The key thing seems to be this comment:

The short answer is not to confuse the bundle org.apache.log4j with the bundle org.apache.logging.logj4. The problem is specifically in the latter not the former [...]

So, while the version that we have is 1.x, it looks like it is not the one with the vulnerability.

Furthermore, the message thread here, it seems that even with the problematic bundle, the problem is unlikely to affect us. It is word reading. I'll just quote a little bit:

This is more of a problem for web server applications than for desktop applications like Eclipse. Web server applications might be attacked if they log uses names or user agent strings. Attackers can actively seek out and target vulnerable applications. Desktop application that act as web clients can also be attacked, but they probably pose harder targets. Attackers have to somehow trick users to connect to malicious services and download malicious data.

Having said that, it would probably make you feel safer to really update to a more recent version. I'm looking into this, but since plain Papyrus includes the 1.2.15 bundle, it would entail at the very least a Papyrus feature patch. One problem is that apparently the API for log4j2 is not the same, so it wouldn't be as simple as updating dependency versions. This link describes a "bridge" between the two, and here it states that the bridge is provided by the log4j-1.2-api jar. Note the version number. Since it is a 1.2 and the plugin we have is 1.2.15, perhaps the plugin already includes the bridge, which might explain why it would be ok to just keep that bundle.

In any case, I need to investigate more closely and see the ramifications, how many bundles in both plain Papyrus and Papyrus CX are impacted, where exactly it is used, and with which API. I'll post as soon as I have more details.

[emammoser]

First, I wanted to make a distinction between (plain) Papyrus and Papyrus CX. We develop the later, not the former. So any problems with (plain) Papyrus are more difficult to solve because we do not control it. Since we are still based on an older version (4.8 2020-06), if something needs to be changed, we can only do feature patches. And this usually is more difficult than just updating our own plugins.

Understood.

As far as log4j1 and whether or not we are affected by that particular CVE, there are many other CVEs with Log4j1. My guess is that the heartburn is coming from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5645 although we don't know for sure. I could reach out to our security team to ask if there was a specific CVE they were concerned with, but their only request of us right now was to upgrade to log4j2 and my guess is that they specifically flagged the file installed in the plugins folder of papyrus.

Having said that, it would probably make you feel safer to really update to a more recent version.

Thank you. I will reach out to our security team to find out exactly what they flagged and why so we have more information going forward.

[eposse]

More details. A lot of info I've found online suggests that the problems are mostly with Log4j 2.x rather then Log4j 1.x, at least in Eclipse projects, which is a bit confusing. See for example the links at the end of this message.

Nevertheless, I found a message on the Papyrus Wiki saying that as of Papyrus 6.4 they are migrating to log4j2. So the solution might be to do Issue #471 first. See [3]. The caveat is that page says that it is updating to a version between 2.17 and 3.0. The problem is that 2.17 still appears as vulnerable in several CVEs. So it's possible that not even upgrading Papyrus will get the latest version of log4j2. In any case, it seems that doing this upgrade in Papyrus might be a huge task.

My preliminary investigation suggests that EMF Compare (and therefore Papyrus Compare) are also dependent on the org.apache.log4j 1.2.15 bundle. If that's the case, the update required might be huge as well.

And Papyrus depends on Xtext, which also uses the 1.2.15 bundle. Fixing that one would be an even bigger issue, and not even their own developers have the resources to upgrade. See [0].

Nevertheless I'm still investigating what I could do.

[0] https://github.com/eclipse/xtext-core/issues/1363#issuecomment-995758908 [1] https://www.eclipse.org/lists/cross-project-issues-dev/msg18753.html [2] Most of the CVEs at https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=log4j including the one you mentioned. [3] https://wiki.eclipse.org/Papyrus/Papyrus_Developer_Guide/Papyrus_Log

[eposse]

More info:

Preliminary impact results for the number of features and plugins that depend on org.apache.log4j 1.x:

• on Papyrus CX

  • 1 feature
  • 2 plugins

• on plain Papyrus (not including Papyrus CX, nor any Papyrus dependencies, like EMF Compare, or Xtext)

  • 4 features
  • 29 plugins

• on Papyrus Compare

  • 1 feature
  • 1 plugin

• on EMF Compare

  • 7 features
  • 7 plugins

• on Xtext (estimated, at least, counting only the ones bundled with Papyrus)

  • 7 features
  • 11 plugins

This means that updating all of these may be an extremely difficult task. In particular anything to do with Papyrus, Xtext and EMF Compare. I'm not even included other components that these may depend on, as the dependencies may continue transitively. Each of these are very complex pieces of software, developed over a very long time, and by others, not by Zeligsoft. This is making me think that the only path forward would be to upgrade to a more recent version of Papyrus (6.5), but even then, there is no guarantee that it will satisfy your IT Security department.

I'm going to take a look at how hard it would be to upgrade to Papyrus 6.5. From my last discussions with Young-Soo, apparently the blocking issue was Papyrus Compare which depended on 4.8.

[emammoser]

We agree here that moving to the newest papyrus might be the best solution and could kill two birds with one stone (Removing log4j1 and upgrading papyrus). Papyrus compare is a concern for us, but right now we are open to any options available to us.

[eposse]

I am working on #471 even though it doesn't have the "NGC: Approved to work" label. Will you put the label on it?

I'll comment on the current status in that issue.

[emammoser]

Added the label to #471

[eposse]

Relevant links:

[1] CISA official log4j vulnerability guidance [2] CVE-2021-44228_scanner: provides a script endorsed by CISA in [1] to check for the vulnerability. See the results below. [3] CISA Mitigating Log4Shell and Other Log4j-Related Vulnerabilities

The result from running the script on Papyrus yields this:

❯ checkjndi.py .
./plugins/org.apache.logging.log4j_2.17.1.v20220106-2156.jar contains "JndiLookup.class" ** BUT APPEARS TO BE PATCHED **
No vulnerable components found

Note in particular that it does not issue any warnings about org.apache.log4j_1.2.24 which is included in Papyrus, as I reported in #471.

You might want to inform your security team about this.

[J17359]

Thanks for the info @eposse ! I just forwarded those links along with a scan of our software using the US govt's scanner tool. No vulnerabilities were found in our software either. I'll see what they say.

[eposse]

I'm just adding here, for reference, a link to the Apache Log4j page where they are tracking security vulnerabilities, and which versions fix which CVEs.

Apache Log4j Security Vulnerabilities

Note that the latest version available to us, and the one I'm upgrading to is 2.17.1, which includes fixes to all the major known vulnerabilities.

Also note, if you look at that page, that Log4j 1.x is not impacted by almost any of the major vulnerabilities, and the ones that do, the risk is significantly lower. Nevertheless, I'm proceeding with the upgrade.

[eposse]

Just adding a note here to mention that we finally have a build free of log4j 1 (see Issue #471) but it needs to be tested. The RPM and ZIP files can be obtained here: https://github.com/ZeligsoftDev/CX4CBDDS/actions/runs/6964003287.

It requires Java 17. Preliminary tests on CentOS 7 seem to be showing it is working fine.

[eposse]

Closing as agreed with @j26151 by e-mail on February 26, 2024.