Hello James and Brian and wildfly developers (and Happy New Year),
Further to my email below, after discussion with the apache log4j team a new CVE has been raised,
https://nvd.nist.gov/vuln/detail/CVE-2019-17571, which is for version 1 of log4j. It is analogous to the one that was raised for version 2, namely,
https://nvd.nist.gov/vuln/detail/CVE-2017-5645.
I am slightly disappointed that the CVE was raised without the accompanying fix that is available by examining the patch made available by Red Hat. I was hoping that we would wind up with version 1.2.18 with the fix. This would have meant
that projects that depend on log4j-v1 would be able to dodge the CVE issue by simply upgrading to the new version. But log4j-v1 really is at end of life and the apache log4j people don’t want to keep it going by patching it every time a new CVE issue is discovered.
That’s understandable, but disappointing nonetheless, because there are some significant projects that depend on log4j-v1 and those projects are now vulnerable via the transitive dependency. This includes wildfly.
In the light of this new CVE I hope that wildfly will reconsider depending on log4j-v1 and make plans for migrating to log4j2.
There is some time before projects such as wildfly will be flagged by the owasp dependency checker; the log4j-v1 CVE has not yet had a base score assigned. But I am presuming it will be 9.8 critical, same as for the log4j2 CVE. There is
an exploit that has been published that uses the ysoserial toolkit, developed for log4j2 but should also apply to the deserialisation that is done in log4j-v1. See
https://github.com/pimps/CVE-2017-5645/blob/master/log4j%20advisory.txt for details.
From: Marlow, Andrew
Sent: 18 December 2019 06:58
To: James Perkins <jperkins@redhat.com>; Brian Stansberry <brian.stansberry@redhat.com>
Cc: agents@andrewpetermarlow.co.uk; wildfly-dev@lists.jboss.org
Subject: RE: EXTERNAL: Re: [wildfly-dev] wildfly and transitive dependency to log4j-v1, possibly via apache cxf
My reply below:
From:
wildfly-dev-bounces@lists.jboss.org <wildfly-dev-bounces@lists.jboss.org>
On Behalf Of James Perkins
Sent: 04 December 2019 00:52
To: Brian Stansberry <brian.stansberry@redhat.com>
Cc: agents@andrewpetermarlow.co.uk;
wildfly-dev@lists.jboss.org
Subject: EXTERNAL: Re: [wildfly-dev] wildfly and transitive dependency to log4j-v1, possibly via apache cxf
On Tue, Dec 3, 2019 at 2:59 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:
On Mon, Dec 2, 2019 at 12:40 PM James Perkins <jperkins@redhat.com> wrote:
Unfortunately we can't remove log4j support. We also need to support log4j v1 for legacy application support.
I am not sure what you’re saying here. Are you saying that wildfly must always stay on log4j-v1 for reasons of backward compatibility? What about the fact that log4j-v1 was end-of-life’d back in 2015? And that it does contain a CVE? Is backward compatibility still a requirement?
We actually use a fork [1] of log4j which delegates the actual logging to the JBoss Log Manager.
That is a fork though; i.e. WildFly itself does not ship log4j:log4j.
I realise that wildfly does not ship log4j; it just depends on it.A number of our testsuite modules do declare log4j:log4j as a test dependency, but AIUI org.jboss.logmanager:log4j-jboss-logmanager is API compatible so is it possible to instead have the testsuite depend on the fork and eliminate this dependency?
Yes the org.jboss.logmanager:log4j-jboss-logmanager can be used as a replacement of log4j. The only requirement is that the org.jboss.logmanager:jboss-logmanager also be on the class path. That is what we use with the shipped zips. We do
not ship an Apache log4j library.
[1]: https://github.com/jboss-logging/log4j-jboss-logmanager
On Sun, Dec 1, 2019 at 2:03 AM Andrew Marlow <marlow.agents@gmail.com> wrote:
Hello everyone,
I am trying to build the latest wildfly from a clone of the github repo at https://github.com/bstansberry/wildfly.git. I understand this is the latest and is from the principal maintainer, Brian Stansberry. I've changed the pom references to the old log4j-v1 to the new log4j-v2 but a pom dependency analysis reveals there is a still a dependency on v1. I am at a loss as to where exactly it is coming from. I hope someone here can shed some light please.