wildfly and transitive dependency to log4j-v1, possibly via apache cxf

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

wildfly and transitive dependency to log4j-v1, possibly via apache cxf

marlowa
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.

The relevant part of the dependency tree is shown from the extract below:

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
   :
INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  
Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?
--

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

Tom Jenkinson
Hi Andrew,

From reading your email I would think you should be looking at https://github.com/wildfly/wildfly rather than Brian's fork?

Regarding the question, my guess (just based on the proximity of this dependency) is it comes from https://github.com/jbossws/jbossws-cxf/blob/jbossws-cxf-5.3.0.Final/pom.xml#L97 (but it might just be a coincidence that is the same version). I think to enforce a version of log4j it would be added under https://github.com/wildfly/wildfly/blob/master/pom.xml#L422?

Thanks,
Tom



On Sun, 1 Dec 2019 at 10:03, Andrew Marlow <[hidden email]> 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.

The relevant part of the dependency tree is shown from the extract below:

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
   :
INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  
Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?
--
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

Jim Ma
On 12/2/19 7:35 PM, Tom Jenkinson wrote:
Hi Andrew,

From reading your email I would think you should be looking at https://github.com/wildfly/wildfly rather than Brian's fork?

Regarding the question, my guess (just based on the proximity of this dependency) is it comes from https://github.com/jbossws/jbossws-cxf/blob/jbossws-cxf-5.3.0.Final/pom.xml#L97 (but it might just be a coincidence that is the same version).


Yes. It comes from jbossws-cxf.    We never tested cxf 3.3.4 and jbossws-cxf 5.3.0.Final with log4j v2 , so we don't know if this works without issues.


I think to enforce a version of log4j it would be added under https://github.com/wildfly/wildfly/blob/master/pom.xml#L422?

Thanks,
Tom



On Sun, 1 Dec 2019 at 10:03, Andrew Marlow <[hidden email]> 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.

The relevant part of the dependency tree is shown from the extract below:

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
   :
INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  
Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?
--
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

James Perkins
In reply to this post by marlowa
Unfortunately we can't remove log4j support. We also need to support log4j v1 for legacy application support. We actually use a fork [1] of log4j which delegates the actual logging to the JBoss Log Manager.


On Sun, Dec 1, 2019 at 2:03 AM Andrew Marlow <[hidden email]> 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.

The relevant part of the dependency tree is shown from the extract below:

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
   :
INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  
Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?
--
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EXTERNAL: Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

Marlow, Andrew

Hello James and thank you for your quick reply.

 

It is indeed unfortunate that log4j-v1 is to be retained. I think that this will have to result in an official fix to log4j-v1 being made at some point. I think it’s just a matter of time before there is a CVE for log4j-v1.

 

From: [hidden email] <[hidden email]> On Behalf Of James Perkins
Sent: 02 December 2019 18:37
To: [hidden email]
Cc: [hidden email]
Subject: EXTERNAL: Re: [wildfly-dev] wildfly and transitive dependency to log4j-v1, possibly via apache cxf

 

Unfortunately we can't remove log4j support. We also need to support log4j v1 for legacy application support. We actually use a fork [1] of log4j which delegates the actual logging to the JBoss Log Manager.

 

 

On Sun, Dec 1, 2019 at 2:03 AM Andrew Marlow <[hidden email]> 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.

 

The relevant part of the dependency tree is shown from the extract below:

 

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test

   :

INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  

Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?

--

Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


 

--

James R. Perkins

JBoss by Red Hat

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex (International) Limited (No: 2999960) | FIS Apex (UK) Limited (No. 3573008) | FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink Information Services Limited (No: 3827424) all registered in England & Wales with their registered office at 25 Canada Square, London E14 5LQ | FIS Global Execution Services Limited is authorised and regulated by the Financial Conduct Authority | Certegy Card Services Limited (No: 3517639) | Certegy France Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 4215488) | Metavante Technologies Limited (No: 2659326) all registered in England & Wales with their registered office at 1st Floor Tricorn House, 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Clear2Pay Limited, Registered in Scotland (No SC157659), Registered Office: Clear2Pay House, Pitreavie Court, Pitreavie Business Park Queensferry Rd, Dunfermline, Fife, SS, KY11 8UU, Scotland | FIS eProcess Intelligence LLC (UK Branch), UK Establishment Registered in England & Wales (No: FC16527/Branch No. BR000355), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS eProcess Intelligence LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 2032143), Head Office: 601 Riverside Avenue, Jacksonville Florida, FL32204, USA | FIS Investment Systems LLC, UK Establishment Registered in England & Wales (No: FC033836/Branch No. BR018923), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS Investment Systems LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 0881255), Head Office: 377 E. Butterfield Road, Suite 800, Lombard, IL 60148, USA | Calls to and from the companies may be recorded for quality purposes. | All of the named companies are part of FIS (Fidelity National Information Services, Inc.).
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

Brian Stansberry
In reply to this post by James Perkins


On Mon, Dec 2, 2019 at 12:40 PM James Perkins <[hidden email]> wrote:
Unfortunately we can't remove log4j support. We also need to support log4j v1 for legacy application support. 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.

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?


On Sun, Dec 1, 2019 at 2:03 AM Andrew Marlow <[hidden email]> 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.

The relevant part of the dependency tree is shown from the extract below:

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
   :
INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  
Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?
--
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

James Perkins


On Tue, Dec 3, 2019 at 2:59 PM Brian Stansberry <[hidden email]> wrote:


On Mon, Dec 2, 2019 at 12:40 PM James Perkins <[hidden email]> wrote:
Unfortunately we can't remove log4j support. We also need to support log4j v1 for legacy application support. 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.

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.
 


On Sun, Dec 1, 2019 at 2:03 AM Andrew Marlow <[hidden email]> 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.

The relevant part of the dependency tree is shown from the extract below:

INFO [m] org.wildfly:wildfly-ts-integ-smoke:jar:19.0.0.Beta1-SNAPSHOT
INFO [m] +- org.jboss.ws.cxf:jbossws-cxf-client:jar:5.3.0.Final:test
   :
INFO [m] |  +- log4j:log4j:jar:1.2.17:test
  
Initially I thought it might be coming via an old version of apache CXF but I see from the top level pom that version 3.3.4 is being used, which is the latest. Any ideas?
--
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: EXTERNAL: Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

Marlow, Andrew

My reply below:

 

From: [hidden email] <[hidden email]> On Behalf Of James Perkins
Sent: 04 December 2019 00:52
To: Brian Stansberry <[hidden email]>
Cc: [hidden email]; [hidden email]
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 <[hidden email]> wrote:

On Mon, Dec 2, 2019 at 12:40 PM James Perkins <[hidden email]> 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 <[hidden email]> 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.

 

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex (International) Limited (No: 2999960) | FIS Apex (UK) Limited (No. 3573008) | FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink Information Services Limited (No: 3827424) all registered in England & Wales with their registered office at 25 Canada Square, London E14 5LQ | FIS Global Execution Services Limited is authorised and regulated by the Financial Conduct Authority | Certegy Card Services Limited (No: 3517639) | Certegy France Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 4215488) | Metavante Technologies Limited (No: 2659326) all registered in England & Wales with their registered office at 1st Floor Tricorn House, 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Clear2Pay Limited, Registered in Scotland (No SC157659), Registered Office: Clear2Pay House, Pitreavie Court, Pitreavie Business Park Queensferry Rd, Dunfermline, Fife, SS, KY11 8UU, Scotland | FIS eProcess Intelligence LLC (UK Branch), UK Establishment Registered in England & Wales (No: FC16527/Branch No. BR000355), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS eProcess Intelligence LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 2032143), Head Office: 601 Riverside Avenue, Jacksonville Florida, FL32204, USA | FIS Investment Systems LLC, UK Establishment Registered in England & Wales (No: FC033836/Branch No. BR018923), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS Investment Systems LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 0881255), Head Office: 377 E. Butterfield Road, Suite 800, Lombard, IL 60148, USA | Calls to and from the companies may be recorded for quality purposes. | All of the named companies are part of FIS (Fidelity National Information Services, Inc.).
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

FW: EXTERNAL: Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

Marlow, Andrew

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 <[hidden email]>; Brian Stansberry <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: EXTERNAL: Re: [wildfly-dev] wildfly and transitive dependency to log4j-v1, possibly via apache cxf

 

My reply below:

 

From: [hidden email] <[hidden email]> On Behalf Of James Perkins
Sent: 04 December 2019 00:52
To: Brian Stansberry <[hidden email]>
Cc: [hidden email]; [hidden email]
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 <[hidden email]> wrote:

On Mon, Dec 2, 2019 at 12:40 PM James Perkins <[hidden email]> 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 <[hidden email]> 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.

 

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex (International) Limited (No: 2999960) | FIS Apex (UK) Limited (No. 3573008) | FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink Information Services Limited (No: 3827424) all registered in England & Wales with their registered office at 25 Canada Square, London E14 5LQ | FIS Global Execution Services Limited is authorised and regulated by the Financial Conduct Authority | Certegy Card Services Limited (No: 3517639) | Certegy France Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 4215488) | Metavante Technologies Limited (No: 2659326) all registered in England & Wales with their registered office at 1st Floor Tricorn House, 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Clear2Pay Limited, Registered in Scotland (No SC157659), Registered Office: Clear2Pay House, Pitreavie Court, Pitreavie Business Park Queensferry Rd, Dunfermline, Fife, SS, KY11 8UU, Scotland | FIS eProcess Intelligence LLC (UK Branch), UK Establishment Registered in England & Wales (No: FC16527/Branch No. BR000355), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS eProcess Intelligence LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 2032143), Head Office: 601 Riverside Avenue, Jacksonville Florida, FL32204, USA | FIS Investment Systems LLC, UK Establishment Registered in England & Wales (No: FC033836/Branch No. BR018923), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS Investment Systems LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 0881255), Head Office: 377 E. Butterfield Road, Suite 800, Lombard, IL 60148, USA | Calls to and from the companies may be recorded for quality purposes. | All of the named companies are part of FIS (Fidelity National Information Services, Inc.).
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: FW: EXTERNAL: Re: wildfly and transitive dependency to log4j-v1, possibly via apache cxf

James Perkins
HI Andrew,

On Thu, Jan 2, 2020 at 11:30 PM Marlow, Andrew <[hidden email]> wrote:

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.


This CVE has been fixed in the version of log4j that WildFly ships. See https://github.com/jboss-logging/log4j-jboss-logmanager/pull/15.
 

 

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.


Internally we do not use log4j. There may be some components that do, but I do most of those are for legacy reasons. The biggest reason we cannot remove log4j v1 support is legacy applications that are deployed. From what I've seen it seems to be used quite regularly.

I do agree we really need to provide some support for log4j2 as well. There is https://issues.redhat.com/browse/WFCORE-482 for this and I'd really like to get this done. I've got a project which uses the jboss-logmanager as it's backend log manager and just uses the log4j2 logging API's.
 

 

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 <[hidden email]>; Brian Stansberry <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: RE: EXTERNAL: Re: [wildfly-dev] wildfly and transitive dependency to log4j-v1, possibly via apache cxf

 

My reply below:

 

From: [hidden email] <[hidden email]> On Behalf Of James Perkins
Sent: 04 December 2019 00:52
To: Brian Stansberry <[hidden email]>
Cc: [hidden email]; [hidden email]
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 <[hidden email]> wrote:

On Mon, Dec 2, 2019 at 12:40 PM James Perkins <[hidden email]> 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 <[hidden email]> 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.

 

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. FIS is a trading name of the following companies: Advanced Portfolio Technologies Ltd (No: 6312142) | Clear2Pay Limited (No: 5792457) | Decalog (UK) Limited (No: 2567370) | FIS Apex (International) Limited (No: 2999960) | FIS Apex (UK) Limited (No. 3573008) | FIS Consulting Services (UK) Limited (No: 2486794) | FIS Derivatives Utility Services (UK) Limited (No: 9398140) | FIS Energy Solutions Limited (No: 1889028) | FIS Global Execution Services Limited (No. 3127109) | FIS Global Trading (UK) Limited (No: 2523114) | FIS Investment Systems (UK) Limited (No: 1366010) | FIS Sherwood Systems Group Limited (No: 982833) | FIS Systems Limited (No: 1937159) | FIS Treasury Systems (Europe) Limited (No: 2624209) | FIS Treasury Systems (UK) Limited (No: 2893376) | GL Settle Limited (No: 2396127) | Integrity Treasury Solutions Europe Limited (No: 3289271) | Monis Software Limited (No: 2333925) | Reech Capital Limited (No: 3649490) | Solutions Plus Consulting Services Limited (No: 3839487) | Valuelink Information Services Limited (No: 3827424) all registered in England & Wales with their registered office at 25 Canada Square, London E14 5LQ | FIS Global Execution Services Limited is authorised and regulated by the Financial Conduct Authority | Certegy Card Services Limited (No: 3517639) | Certegy France Limited (No: 2557650) | eFunds International Limited (No: 1930117) | Fidelity Information Services Limited (No: 2225203) | FIS Payments (UK) Limited (No: 4215488) | Metavante Technologies Limited (No: 2659326) all registered in England & Wales with their registered office at 1st Floor Tricorn House, 51-53 Hagley Road, Edgbaston, Birmingham, West Midlands, B16 8TU, United Kingdom | FIS Payments (UK) Limited is authorised and regulated by the Financial Conduct Authority; some services are covered by the Financial Ombudsman Service (in the UK). Clear2Pay Limited, Registered in Scotland (No SC157659), Registered Office: Clear2Pay House, Pitreavie Court, Pitreavie Business Park Queensferry Rd, Dunfermline, Fife, SS, KY11 8UU, Scotland | FIS eProcess Intelligence LLC (UK Branch), UK Establishment Registered in England & Wales (No: FC16527/Branch No. BR000355), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS eProcess Intelligence LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 2032143), Head Office: 601 Riverside Avenue, Jacksonville Florida, FL32204, USA | FIS Investment Systems LLC, UK Establishment Registered in England & Wales (No: FC033836/Branch No. BR018923), Registered Branch Office: 25 Canada Square, London, E14 5LQ; FIS Investment Systems LLC is a limited liability company formed in the USA registered on file with the Office of the Delaware Secretary of State, Division of Corporations (File No. 0881255), Head Office: 377 E. Butterfield Road, Suite 800, Lombard, IL 60148, USA | Calls to and from the companies may be recorded for quality purposes. | All of the named companies are part of FIS (Fidelity National Information Services, Inc.).


--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev