Re: Maven Dependency Plugin - Log4j vulnerabilities

[Michael Osipov]

Guys,

please stop spamming the dev mailing list with this. Take the problem 
off list, since this is not a Maven problem.


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Piotr Żygieło]

> https://github.com/jveverka/mvn-dependency-log4j/commit/ac87977c19bb2ee2564d15fa87f255d621a4706d
https://github.com/pzygielo/mvn-dependency-log4j/runs/5425284512?check_suite_focus=true#step:5:1

No log4j:1.2.12:jar is downloaded in that reproducer.

log4j/log4j is excluded by commons-logging from its dependencies.

-- 
Piotrek

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Juraj Veverka]

Hi David

Thank you for summarizing the problem, let me explain some details:
1. "The business application is not exposed" - true
2. "The maven build environment might (can’t confirm at this point)
download a transitive dependency on log4j 1.x" - this is true, build
environment and maven-dependency-plugin in particular is downloading log4j
1.2.12.
It is true that runtime is not affected, but it will be definitely better
in log4j 1.2.12 dependency is completely removed. I changed the previous
example to show that maven-dependency-plugin is indeed affected.

https://github.com/jveverka/mvn-dependency-log4j/commit/ac87977c19bb2ee2564d15fa87f255d621a4706d

Can you send me the list of affected projects?  I will try to prepare pull
requests to remove log4j 1.2.12.

Thanks

On Thu, Mar 3, 2022 at 11:31 AM Jaladi, Venumadhav <
jaladi.venumad...@verizon.com> wrote:

> Hi David,
>
> Thanks for the summary and the suggestion. Sure, we will look at how best
> we can handle this with our Security team.
>
> Thanks,
> Venu
>
>
> On Thu, Mar 3, 2022 at 4:20 AM David Milet  wrote:
>
>> Hey guys
>> Let’s be courteous and civil.
>>
>> As part of vulnerability management, an assessment has to be made about
>> the potential security impact of a vulnerability in software.
>>
>> New vulnerabilities are found every day on older components and it is not
>> practical nor feasible to chase down every rabbit.
>>
>> What I read from this chain is
>> 1. The business application is not exposed to any log4j vulnerability -
>> that’s the most important
>> 2. The maven build environment might (can’t confirm at this point)
>> download a transitive dependency on log4j 1.x which has a newly found
>> vulnerability. IMHO the impact is low. it’s a build environment, not actual
>> business application and you surely don’t (and shouldn’t) build on your
>> production systems. The probability of occurrence of an attack on this is
>> probably null, knowing that attack vectors on log4j involve tricking the
>> exposed application into logging something malicious, and a build
>> environment does not expose logging to outside like a web app would.
>> Based on this, I’d flag those occurrences at the scanner as assessed and
>> ignored and move on.
>>
>> As a best practice, clean up your build environment after each build. Or
>> use ephemeral containerized build environments.
>>
>>
>>
>> > On Mar 3, 2022, at 02:53, Thomas Matthijs  wrote:
>> >
>> > That was just to demonstrate how i got the dependency chain, that file
>> > was there, but if you're going to be this hostile, i'm not interested
>> > anymore, muting thread
>> >
>> >> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
>> wrote:
>> >>
>> >>> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs 
>> wrote:
>> >>>
>> >>> Can confirm this project downloads log4j 1.12.12 for me
>> >>
>> >> As I see it - you confirm something else.
>> >>
>> >>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>> >>
>> >> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>> >> _artifact descriptor_
>> >>
>> >> --
>> >> Piotrek
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >>
>>
>

-- 

Best Regards


--

Juraj Veverka  | Solution Design Architect

M +421 917 521 285

www.globallogic.sk  

   [image: GLTwitter]





http://www.globallogic.com/Disclaimer.htm

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Jaladi, Venumadhav]

Hi David,

Thanks for the summary and the suggestion. Sure, we will look at how best
we can handle this with our Security team.

Thanks,
Venu


On Thu, Mar 3, 2022 at 4:20 AM David Milet  wrote:

> Hey guys
> Let’s be courteous and civil.
>
> As part of vulnerability management, an assessment has to be made about
> the potential security impact of a vulnerability in software.
>
> New vulnerabilities are found every day on older components and it is not
> practical nor feasible to chase down every rabbit.
>
> What I read from this chain is
> 1. The business application is not exposed to any log4j vulnerability -
> that’s the most important
> 2. The maven build environment might (can’t confirm at this point)
> download a transitive dependency on log4j 1.x which has a newly found
> vulnerability. IMHO the impact is low. it’s a build environment, not actual
> business application and you surely don’t (and shouldn’t) build on your
> production systems. The probability of occurrence of an attack on this is
> probably null, knowing that attack vectors on log4j involve tricking the
> exposed application into logging something malicious, and a build
> environment does not expose logging to outside like a web app would.
> Based on this, I’d flag those occurrences at the scanner as assessed and
> ignored and move on.
>
> As a best practice, clean up your build environment after each build. Or
> use ephemeral containerized build environments.
>
>
>
> > On Mar 3, 2022, at 02:53, Thomas Matthijs  wrote:
> >
> > That was just to demonstrate how i got the dependency chain, that file
> > was there, but if you're going to be this hostile, i'm not interested
> > anymore, muting thread
> >
> >> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> wrote:
> >>
> >>> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> >>>
> >>> Can confirm this project downloads log4j 1.12.12 for me
> >>
> >> As I see it - you confirm something else.
> >>
> >>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >>
> >> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >> _artifact descriptor_
> >>
> >> --
> >> Piotrek
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Jaladi, Venumadhav]

Adding Juraj back in the chain as I see that he is removed.

Juraj,

Can you please look at the below  6 emails in this chain?

Thanks,
Venu


On Thu, Mar 3, 2022 at 3:07 AM John Patrick  wrote:

> Sorry I thought you where talking about log4j v2, not v1. I can see it
> downloads the metadata about the project but non or the jars;
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j/log4j/1.2.12/_remote.repositories
>
> So I would still say false positive, as the jar is not actually used.
>
> But looking at the dependency tree it would need the apache commons to
> update commons-logging:commons-logging, then
> ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
> then it gets to the 1st dependency within the maven ecosystem.
> So 5 ish patches to 5 separate projects to upgrade, test and release, each
> before then next pr can progress.
>
> John
>
>
> On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:
>
>> That was just to demonstrate how i got the dependency chain, that file
>> was there, but if you're going to be this hostile, i'm not interested
>> anymore, muting thread
>>
>> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
>> wrote:
>> >
>> > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
>> > >
>> > > Can confirm this project downloads log4j 1.12.12 for me
>> >
>> > As I see it - you confirm something else.
>> >
>> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>> >
>> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>> > _artifact descriptor_
>> >
>> > --
>> > Piotrek
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Jorge Solórzano]

Just to add my 2 cents:

Many security scanning tools are not smart enough to detect the context, or
in other words, they will mark as an issue a dependency that's only used
with "test" scope even if it's not used in the final jar, and in the same
line, there are some dependencies that can be optional and that might or
might not be present in the final classpath.

Anyway, I agree that since log4shell, for many of us, a (small) security
issue can cause panic, and with the actual events it gets more relevance,
and actually I think it's a good thing since we are now more aware of
security, but the issue is that we need to distinguish case by case if
there is a security issue or not, and not blindly follow the suggestion of
a scanning tool.

Nevertheless, the issue comes from the velocity dependency in this chain:

> [INFO] +- org.apache.maven.reporting:maven-reporting-impl:jar:3.1.0:compile
> [INFO] |  +-
> org.apache.maven.reporting:maven-reporting-api:jar:3.1.0:compile
> [INFO] |  +- org.apache.maven.doxia:doxia-sink-api:jar:1.11.1:compile
> [INFO] |  |  \- org.apache.maven.doxia:doxia-logging-api:jar:1.11.1:compile
> [INFO] |  +-
> org.apache.maven.doxia:doxia-decoration-model:jar:1.11.1:compile
> [INFO] |  +- org.apache.maven.doxia:doxia-core:jar:1.11.1:compile
> [INFO] |  |  +-
> org.codehaus.plexus:plexus-container-default:jar:2.1.0:compile
> [INFO] |  |  |  +- org.apache.xbean:xbean-reflect:jar:3.7:compile
> [INFO] |  |  |  \-
> com.google.collections:google-collections:jar:1.0:compile
> [INFO] |  |  +- org.apache.commons:commons-text:jar:1.3:compile
> [INFO] |  |  +- org.apache.httpcomponents:httpclient:jar:4.5.13:compile
> [INFO] |  |  |  \- commons-codec:commons-codec:jar:1.11:compile
> [INFO] |  |  \- org.apache.httpcomponents:httpcore:jar:4.4.14:compile
> [INFO] |  \- org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1:compile
> [INFO] | +- org.apache.maven.doxia:doxia-skin-model:jar:1.11.1:compile
> [INFO] | +-
> org.apache.maven.doxia:doxia-module-xhtml:jar:1.11.1:compile
> [INFO] | +-
> org.apache.maven.doxia:doxia-module-xhtml5:jar:1.11.1:compile
> [INFO] | +- org.codehaus.plexus:plexus-i18n:jar:1.0-beta-10:compile
> [INFO] | +- org.codehaus.plexus:plexus-velocity:jar:1.2:compile
> [INFO] | +- org.apache.velocity:velocity:jar:1.7:compile
> [INFO] | |  \- commons-lang:commons-lang:jar:2.4:compile
> [INFO] | \- org.apache.velocity:velocity-tools:jar:2.0:compile
> [INFO] |+- commons-digester:commons-digester:jar:1.8:compile
> [INFO] |+- commons-chain:commons-chain:jar:1.1:compile
> [INFO] |+- dom4j:dom4j:jar:1.1:compile
> [INFO] |\- oro:oro:jar:2.0.8:compile
>

The velocity version that the doxia-site-renderer dependency uses is
org.apache.velocity:velocity:jar:1.7:compile, and the velocity dependency
declares this:

> 
>   log4j
>   log4j
>   1.2.12
>   provided
> 
>

So, the root issue comes from the doxia-site-renderer that uses an old
(29-Nov-201) version of velocity.


On Fri, Mar 4, 2022 at 7:41 AM Ralph Goers 
wrote:

> This appears to be plugin dependencies though, not project dependencies.
> The
> issue should really be raised with whatever plugin is causing it to be
> used. My
> recollection is that Maven itself hasn’t used Log4j in quite some time for
> logging.
>
> Ralph
>
> > On Mar 3, 2022, at 8:21 AM, Gary Gregory  wrote:
> >
> > Also note that in log4j 2.17.2 that was released a few days ago, I added
> > many improvements to the log4j-1.2-api module which aims to provide
> > compatibility with 1.2.
> >
> > Gary
> >
> > On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels 
> wrote:
> >
> >> All of the (known) remaining log4j1.x security bugs (none of which are
> as
> >> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
> >> with 1.2 you should use that. Otherwise you can try to migrate to the
> log4j
> >> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
> >>
> >> Gruss
> >> Bernd
> >> --
> >> http://bernd.eckenfels.net
> >> ____
> >> Von: Martin Gainty 
> >> Gesendet: Thursday, March 3, 2022 1:18:50 PM
> >> An: Maven Developers List 
> >> Cc: David Milet ; iss...@maven.apache.org <
> >> iss...@maven.apache.org>; VZ-Product-OneTalk <
> >> vz-product-onet...@verizon.com>; Danylo Volokh <
> >> danylo.vol...@globallogic.com>
> >> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
> >>
> >> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
> >> Vulnerabity?
> >> Is this not th

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Ralph Goers]

This appears to be plugin dependencies though, not project dependencies. The 
issue should really be raised with whatever plugin is causing it to be used. My 
recollection is that Maven itself hasn’t used Log4j in quite some time for 
logging. 

Ralph

> On Mar 3, 2022, at 8:21 AM, Gary Gregory  wrote:
> 
> Also note that in log4j 2.17.2 that was released a few days ago, I added
> many improvements to the log4j-1.2-api module which aims to provide
> compatibility with 1.2.
> 
> Gary
> 
> On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels  wrote:
> 
>> All of the (known) remaining log4j1.x security bugs (none of which are as
>> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
>> with 1.2 you should use that. Otherwise you can try to migrate to the log4j
>> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
>> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: Martin Gainty 
>> Gesendet: Thursday, March 3, 2022 1:18:50 PM
>> An: Maven Developers List 
>> Cc: David Milet ; iss...@maven.apache.org <
>> iss...@maven.apache.org>; VZ-Product-OneTalk <
>> vz-product-onet...@verizon.com>; Danylo Volokh <
>> danylo.vol...@globallogic.com>
>> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
>> 
>> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
>> Vulnerabity?
>> Is this not the case?
>> Thanks John
>> M.
>> 
>> 
>> 
>> Sent from my Verizon, Samsung Galaxy smartphone
>> 
>> 
>> 
>>  Original message 
>> From: John Patrick 
>> Date: 3/3/22 4:07 AM (GMT-05:00)
>> To: Maven Developers List 
>> Cc: David Milet , iss...@maven.apache.org,
>> VZ-Product-OneTalk , Danylo Volokh <
>> danylo.vol...@globallogic.com>
>> Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities
>> 
>> Sorry I thought you where talking about log4j v2, not v1. I can see it
>> downloads the metadata about the project but non or the jars;
>> local-repo/log4j
>> local-repo/log4j/log4j
>> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
>> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
>> local-repo/log4j
>> local-repo/log4j/log4j
>> local-repo/log4j/log4j/1.2.12
>> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
>> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
>> local-repo/log4j/log4j/1.2.12/_remote.repositories
>> 
>> So I would still say false positive, as the jar is not actually used.
>> 
>> But looking at the dependency tree it would need the apache commons to
>> update commons-logging:commons-logging, then
>> ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
>> then it gets to the 1st dependency within the maven ecosystem.
>> So 5 ish patches to 5 separate projects to upgrade, test and release, each
>> before then next pr can progress.
>> 
>> John
>> 
>> 
>> On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:
>> 
>>> That was just to demonstrate how i got the dependency chain, that file
>>> was there, but if you're going to be this hostile, i'm not interested
>>> anymore, muting thread
>>> 
>>> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
>>> wrote:
>>>> 
>>>> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
>>>>> 
>>>>> Can confirm this project downloads log4j 1.12.12 for me
>>>> 
>>>> As I see it - you confirm something else.
>>>> 
>>>>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>>>> 
>>>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>>>> _artifact descriptor_
>>>> 
>>>> --
>>>> Piotrek
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Gary Gregory]

Also note that in log4j 2.17.2 that was released a few days ago, I added
many improvements to the log4j-1.2-api module which aims to provide
compatibility with 1.2.

Gary

On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels  wrote:

> All of the (known) remaining log4j1.x security bugs (none of which are as
> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
> with 1.2 you should use that. Otherwise you can try to migrate to the log4j
> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Martin Gainty 
> Gesendet: Thursday, March 3, 2022 1:18:50 PM
> An: Maven Developers List 
> Cc: David Milet ; iss...@maven.apache.org <
> iss...@maven.apache.org>; VZ-Product-OneTalk <
> vz-product-onet...@verizon.com>; Danylo Volokh <
> danylo.vol...@globallogic.com>
> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
>
> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
> Vulnerabity?
> Is this not the case?
> Thanks John
> M.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
>
>  Original message 
> From: John Patrick 
> Date: 3/3/22 4:07 AM (GMT-05:00)
> To: Maven Developers List 
> Cc: David Milet , iss...@maven.apache.org,
> VZ-Product-OneTalk , Danylo Volokh <
> danylo.vol...@globallogic.com>
> Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities
>
> Sorry I thought you where talking about log4j v2, not v1. I can see it
> downloads the metadata about the project but non or the jars;
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j/log4j/1.2.12/_remote.repositories
>
> So I would still say false positive, as the jar is not actually used.
>
> But looking at the dependency tree it would need the apache commons to
> update commons-logging:commons-logging, then
> ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
> then it gets to the 1st dependency within the maven ecosystem.
> So 5 ish patches to 5 separate projects to upgrade, test and release, each
> before then next pr can progress.
>
> John
>
>
> On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:
>
> > That was just to demonstrate how i got the dependency chain, that file
> > was there, but if you're going to be this hostile, i'm not interested
> > anymore, muting thread
> >
> > On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> > wrote:
> > >
> > > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > > >
> > > > Can confirm this project downloads log4j 1.12.12 for me
> > >
> > > As I see it - you confirm something else.
> > >
> > > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > > _artifact descriptor_
> > >
> > > --
> > > Piotrek
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Gary Gregory]

Do note that reload4j is not 100% compatible with log4j 1.2.17, code has
just be deleted to "fix" some CVEs.

Gary

On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels  wrote:

> All of the (known) remaining log4j1.x security bugs (none of which are as
> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
> with 1.2 you should use that. Otherwise you can try to migrate to the log4j
> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Martin Gainty 
> Gesendet: Thursday, March 3, 2022 1:18:50 PM
> An: Maven Developers List 
> Cc: David Milet ; iss...@maven.apache.org <
> iss...@maven.apache.org>; VZ-Product-OneTalk <
> vz-product-onet...@verizon.com>; Danylo Volokh <
> danylo.vol...@globallogic.com>
> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
>
> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
> Vulnerabity?
> Is this not the case?
> Thanks John
> M.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
>
>  Original message 
> From: John Patrick 
> Date: 3/3/22 4:07 AM (GMT-05:00)
> To: Maven Developers List 
> Cc: David Milet , iss...@maven.apache.org,
> VZ-Product-OneTalk , Danylo Volokh <
> danylo.vol...@globallogic.com>
> Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities
>
> Sorry I thought you where talking about log4j v2, not v1. I can see it
> downloads the metadata about the project but non or the jars;
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j/log4j/1.2.12/_remote.repositories
>
> So I would still say false positive, as the jar is not actually used.
>
> But looking at the dependency tree it would need the apache commons to
> update commons-logging:commons-logging, then
> ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
> then it gets to the 1st dependency within the maven ecosystem.
> So 5 ish patches to 5 separate projects to upgrade, test and release, each
> before then next pr can progress.
>
> John
>
>
> On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:
>
> > That was just to demonstrate how i got the dependency chain, that file
> > was there, but if you're going to be this hostile, i'm not interested
> > anymore, muting thread
> >
> > On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> > wrote:
> > >
> > > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > > >
> > > > Can confirm this project downloads log4j 1.12.12 for me
> > >
> > > As I see it - you confirm something else.
> > >
> > > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > > _artifact descriptor_
> > >
> > > --
> > > Piotrek
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Bernd Eckenfels]

All of the (known) remaining log4j1.x security bugs (none of which are as 
severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick with 
1.2 you should use that. Otherwise you can try to migrate to the log4j bridge, 
it’s compatibility was increased in 2.17.2 or 2.12.4.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Martin Gainty 
Gesendet: Thursday, March 3, 2022 1:18:50 PM
An: Maven Developers List 
Cc: David Milet ; iss...@maven.apache.org 
; VZ-Product-OneTalk ; 
Danylo Volokh 
Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities

I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security 
Vulnerabity?
Is this not the case?
Thanks John
M.



Sent from my Verizon, Samsung Galaxy smartphone



 Original message 
From: John Patrick 
Date: 3/3/22 4:07 AM (GMT-05:00)
To: Maven Developers List 
Cc: David Milet , iss...@maven.apache.org, 
VZ-Product-OneTalk , Danylo Volokh 

Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities

Sorry I thought you where talking about log4j v2, not v1. I can see it
downloads the metadata about the project but non or the jars;
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j/log4j/1.2.12/_remote.repositories

So I would still say false positive, as the jar is not actually used.

But looking at the dependency tree it would need the apache commons to
update commons-logging:commons-logging, then
ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
then it gets to the 1st dependency within the maven ecosystem.
So 5 ish patches to 5 separate projects to upgrade, test and release, each
before then next pr can progress.

John


On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:

> That was just to demonstrate how i got the dependency chain, that file
> was there, but if you're going to be this hostile, i'm not interested
> anymore, muting thread
>
> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> wrote:
> >
> > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > >
> > > Can confirm this project downloads log4j 1.12.12 for me
> >
> > As I see it - you confirm something else.
> >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >
> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > _artifact descriptor_
> >
> > --
> > Piotrek
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

RE: Maven Dependency Plugin - Log4j vulnerabilities

[Martin Gainty]

I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security 
Vulnerabity?
Is this not the case?
Thanks John
M.



Sent from my Verizon, Samsung Galaxy smartphone



 Original message 
From: John Patrick 
Date: 3/3/22 4:07 AM (GMT-05:00)
To: Maven Developers List 
Cc: David Milet , iss...@maven.apache.org, 
VZ-Product-OneTalk , Danylo Volokh 

Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities

Sorry I thought you where talking about log4j v2, not v1. I can see it
downloads the metadata about the project but non or the jars;
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j/log4j/1.2.12/_remote.repositories

So I would still say false positive, as the jar is not actually used.

But looking at the dependency tree it would need the apache commons to
update commons-logging:commons-logging, then
ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
then it gets to the 1st dependency within the maven ecosystem.
So 5 ish patches to 5 separate projects to upgrade, test and release, each
before then next pr can progress.

John


On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:

> That was just to demonstrate how i got the dependency chain, that file
> was there, but if you're going to be this hostile, i'm not interested
> anymore, muting thread
>
> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> wrote:
> >
> > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > >
> > > Can confirm this project downloads log4j 1.12.12 for me
> >
> > As I see it - you confirm something else.
> >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >
> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > _artifact descriptor_
> >
> > --
> > Piotrek
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[David Milet]

Hey guys
Let’s be courteous and civil.

As part of vulnerability management, an assessment has to be made about the 
potential security impact of a vulnerability in software.

New vulnerabilities are found every day on older components and it is not 
practical nor feasible to chase down every rabbit.

What I read from this chain is 
1. The business application is not exposed to any log4j vulnerability - that’s 
the most important 
2. The maven build environment might (can’t confirm at this point) download a 
transitive dependency on log4j 1.x which has a newly found vulnerability. IMHO 
the impact is low. it’s a build environment, not actual business application 
and you surely don’t (and shouldn’t) build on your production systems. The 
probability of occurrence of an attack on this is probably null, knowing that 
attack vectors on log4j involve tricking the exposed application into logging 
something malicious, and a build environment does not expose logging to outside 
like a web app would.
Based on this, I’d flag those occurrences at the scanner as assessed and 
ignored and move on.

As a best practice, clean up your build environment after each build. Or use 
ephemeral containerized build environments.



> On Mar 3, 2022, at 02:53, Thomas Matthijs  wrote:
> 
> That was just to demonstrate how i got the dependency chain, that file
> was there, but if you're going to be this hostile, i'm not interested
> anymore, muting thread
> 
>> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło  wrote:
>> 
>>> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
>>> 
>>> Can confirm this project downloads log4j 1.12.12 for me
>> 
>> As I see it - you confirm something else.
>> 
>>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>> 
>> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>> _artifact descriptor_
>> 
>> --
>> Piotrek
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[John Patrick]

Sorry I thought you where talking about log4j v2, not v1. I can see it
downloads the metadata about the project but non or the jars;
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j
local-repo/log4j/log4j
local-repo/log4j/log4j/1.2.12
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
local-repo/log4j/log4j/1.2.12/_remote.repositories

So I would still say false positive, as the jar is not actually used.

But looking at the dependency tree it would need the apache commons to
update commons-logging:commons-logging, then
ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
then it gets to the 1st dependency within the maven ecosystem.
So 5 ish patches to 5 separate projects to upgrade, test and release, each
before then next pr can progress.

John


On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:

> That was just to demonstrate how i got the dependency chain, that file
> was there, but if you're going to be this hostile, i'm not interested
> anymore, muting thread
>
> On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> wrote:
> >
> > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > >
> > > Can confirm this project downloads log4j 1.12.12 for me
> >
> > As I see it - you confirm something else.
> >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> >
> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > _artifact descriptor_
> >
> > --
> > Piotrek
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Thomas Matthijs]

That was just to demonstrate how i got the dependency chain, that file
was there, but if you're going to be this hostile, i'm not interested
anymore, muting thread

On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło  wrote:
>
> On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> >
> > Can confirm this project downloads log4j 1.12.12 for me
>
> As I see it - you confirm something else.
>
> > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
>
> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> _artifact descriptor_
>
> --
> Piotrek
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Piotr Żygieło]

On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
>
> Can confirm this project downloads log4j 1.12.12 for me

As I see it - you confirm something else.

> Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:

Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
_artifact descriptor_

-- 
Piotrek

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Thomas Matthijs]

Hello,

Can confirm this project downloads log4j 1.12.12 for me

rm -rf ~/.m2/repository/log4j/log4j
sudo chown root:root ~/.m2/repository/log4j/log4j

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy
(copy-artifact) on project demo: Execution copy-artifact of goal
org.apache.maven.plugins:maven-dependency-plugin:3.2.0:copy failed:
Plugin org.apache.maven.plugins:maven-dependency-plugin:3.2.0 or one
of its dependencies could not be resolved: Failed to collect
dependencies at
org.apache.maven.plugins:maven-dependency-plugin:jar:3.2.0 ->
org.apache.maven.reporting:maven-reporting-impl:jar:3.0.0 ->
org.apache.maven.doxia:doxia-site-renderer:jar:1.7.4 ->
org.apache.velocity:velocity-tools:jar:2.0 ->
commons-digester:commons-digester:jar:1.8 ->
commons-logging:commons-logging:jar:1.1 -> log4j:log4j:jar:1.2.12:
Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:

So the dependency chain seems to be

org.apache.maven.plugins:maven-dependency-plugin:jar:3.2.0
-> org.apache.maven.reporting:maven-reporting-impl:jar:3.0.0
-> org.apache.maven.doxia:doxia-site-renderer:jar:1.7.4
-> org.apache.velocity:velocity-tools:jar:2.0
-> commons-digester:commons-digester:jar:1.8
-> commons-logging:commons-logging:jar:1.1
-> log4j:log4j:jar:1.2.12:

Regards

On Mon, 28 Feb 2022 at 13:52, Juraj Veverka
 wrote:
>
> Hi David
>
> Many thanks for your email, I really appreciate your reply. This is an
> isolated example of the problem.
> https://github.com/jveverka/mvn-dependency-log4j
> You can find all repro steps there. In case of any questions, feel free
> to contact me.
>
> Kind regards
> Juraj Veverka
>
>
>
> On Mon, Feb 28, 2022 at 12:14 PM David Milet  wrote:
>
> > Where I work we decided to address log4j vulnerabilities only for
> > components directly used by the application and actually performing logging.
> > We ignored transitive dependencies and maven plug-ins.
> > I’m curious about this use case from Venu though, what application would
> > rely on the maven dependency plugin at runtime? Does it mean you’re pulling
> > maven dependencies after application startup?
> >
> > > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
> > wrote:
> > >
> > > Hi,
> > >
> > > Please provide more information, like plugin, mven, os version.
> > >
> > > We also need an example project which reproduces your issue.
> > > When we can't reproduce we can't help.
> > >
> > > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> > >  napisał(a):
> > >
> > >> Hi team,
> > >>
> > >> Can I expect any response?  Is this the right email address for my
> > >> question?
> > >>
> > >> Thanks,
> > >> Venu
> > >>
> > >>
> > >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> > >>> jaladi.venumad...@verizon.com> wrote:
> > >>>
> > >>> Hi team,
> > >>>
> > >>> We are using the Maven Dependency Plugin in one of our projects and our
> > >>> scanning tools are showing multiple vulnerabilities related to Log4j
> > >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> > >>> CVE-2022-23307 and CVE-2021-4104).
> > >>>
> > >>> We would  like to know if there are any plans to release a newer
> > version
> > >>> of Maven Dependency Plugin with the fixes of these
> > >>> vulnerabilities(referring to the latest version of Log4j libraries).
> > If
> > >>> so, is there any planned date for this release?
> > >>>
> > >>> Please let us know any any more information is required.
> > >>>
> > >>> Thanks,
> > >>> Venu
> > >>>
> > >>
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> >
>
> --
>
> Best Regards
>
>
> --
>
> Juraj Veverka  | Solution Design Architect
>
> M +421 917 521 285
>
> www.globallogic.sk  
>
>    [image: GLTwitter]
> 
> 
> 
> 
>
> http://www.globallogic.com/Disclaimer.htm

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Piotr Żygieło]

On Thu, 3 Mar 2022 at 07:27, Jaladi, Venumadhav
>
> Below I am pasting some of the information on the 3 vulnerabilities from
> our report.

It's hard to talk about that report, for (said at least twice) linked
reproducer does not demonstrate to actually download vulnerable
log4j:1.2.12 jar.

-- 
Piotrek

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Jaladi, Venumadhav]

Hi,

Below I am pasting some of the information on the 3 vulnerabilities from
our report.  FYI, I removed the information about the server details and
also trimmed the file path.  This report is generated by the Tenable agent.

Severity scandate Vuln Name Description Summary Fix CVE ID CVS Base
Score Plugin
Output
Critical 3/02/2022 Apache Log4j Unsupported Version Detection According to
its self-reported version number, the installation of Apache Log4j on the
remote host is no longer supported. Log4j reached its end of life prior to
2016.

Lack of support implies that no new security patches for the product will
be released by the vendor. As a result, it is likely to contain security
vulnerabilities. A logging library running on the remote host is no longer
supported. Upgrade to a version of Apache Log4j that is currently supported.

Upgrading to the latest versions for Apache Log4j is highly recommended as
intermediate versions / patches have known high severity vulnerabilities
and the vendor is updating their advisories often as new research and
knowledge about the impact of Log4j is discovered. Refer to
https://logging.apache.org/log4j/2.x/security.html for the latest versions.
  10 Path  :
.../.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar
  Installed version : 1.2.12
Critical 3/02/2022 Apache Log4j 1.x Multiple Vulnerabilities According to
its self-reported version number, the installation of Apache Log4j on the
remote host is 1.x and is no longer supported. Log4j reached its end of
life prior to 2016. Additionally, Log4j 1.x is affected by multiple
vulnerabilities, including :

  - Log4j includes a SocketServer that accepts serialized log events and
deserializes them without verifying whether the objects are allowed or
not. This can provide an attack vector that can be exploited.
(CVE-2019-17571)

  - Improper validation of certificate with host mismatch in Apache Log4j
SMTP appender. This could allow an SMTPS connection to be intercepted
by a man-in-the-middle attack which could leak any log messages sent
through that appender. (CVE-2020-9488)

  - JMSSink uses JNDI in an unprotected manner allowing any application
using the JMSSink to be vulnerable if it is configured to reference an
untrusted site or if the site referenced can be accesseed by the attacker.
(CVE-2022-23302)

Lack of support implies that no new security patches for the product will
be released by the vendor. As a result, it is likely to contain security
vulnerabilities. A logging library running on the remote host has multiple
vulnerabilities. Upgrade to a version of Apache Log4j that is currently
supported.

Upgrading to the latest versions for Apache Log4j is highly recommended as
intermediate versions / patches have known high severity vulnerabilities
and the vendor is updating their advisories often as new research and
knowledge about the impact of Log4j is discovered. Refer to
https://logging.apache.org/log4j/2.x/security.html for the latest
versions. CVE-2019-17571,
CVE-2020-9488, CVE-2022-23302, CVE-2022-23305, CVE-2022-23307 10 Path
: .../.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar
  Installed version : 1.2.12
High 3/02/2022 Apache Log4j 1.2 JMSAppender Remote Code Execution
(CVE-2021-4104) The version of Apache Log4j on the remote host is 1.2. It
is, therefore, affected by a remote code execution vulnerability when
specifically configured to use JMSAppender.

Note that Nessus has not tested for these issues but has instead relied
only on the application's self-reported version number. A package installed
on the remote host is affected by a remote code execution
vulnerability. Upgrade
to Apache Log4j version 2.16.0 or later since 1.x is end of life.

Upgrading to the latest versions for Apache Log4j is highly recommended as
intermediate versions / patches have known high severity vulnerabilities
and the vendor is updating their advisories often as new research and
knowledge about the impact of Log4j is discovered. Refer to
https://logging.apache.org/log4j/2.x/security.html for the latest versions.
CVE-2021-4104 6 Path  :
.../.m2/repository/log4j/log4j/1.2.12/log4j-1.2.12.jar
  Installed version : 1.2.12
  Fixed version : 2.16.0

Thanks,
Venu


On Tue, Mar 1, 2022 at 3:09 PM John Patrick  wrote:

> You might need to raise a bug with your security scanner regarding false
> positives.
>
> So your dependency tree I only see log4j 2.17.1; i.e.
>
> Your Pom
> - org.springframework.boot:spring-boot-starter-web:2.6.4
> -- org.springframework.boot:spring-boot-starter-web:2.6.4
> --- org.springframework.boot:spring-boot-starter:2.6.4
>  org.springframework.boot:spring-boot-starter-logging:2.6.4
> - org.apache.logging.log4j:log4j-to-slf4j:2.17.1
> -- org.apache.logging.log4j:log4j-api:2.17.1
>
> Doing a build "mvn clean install -Dmaven.repo.local=repo"
> Then "find repo -name "*log4j*" -type f", only returns;
> 

Re: Maven Dependency Plugin - Log4j vulnerabilities

[John Patrick]

You might need to raise a bug with your security scanner regarding false
positives.

So your dependency tree I only see log4j 2.17.1; i.e.

Your Pom
- org.springframework.boot:spring-boot-starter-web:2.6.4
-- org.springframework.boot:spring-boot-starter-web:2.6.4
--- org.springframework.boot:spring-boot-starter:2.6.4
 org.springframework.boot:spring-boot-starter-logging:2.6.4
- org.apache.logging.log4j:log4j-to-slf4j:2.17.1
-- org.apache.logging.log4j:log4j-api:2.17.1

Doing a build "mvn clean install -Dmaven.repo.local=repo"
Then "find repo -name "*log4j*" -type f", only returns;
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.jar
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.pom
repo/org/apache/logging/log4j/log4j-api/2.17.1/log4j-api-2.17.1.jar.sha1
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.pom
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.jar
repo/org/apache/logging/log4j/log4j-to-slf4j/2.17.1/log4j-to-slf4j-2.17.1.jar.sha1
repo/org/apache/logging/log4j/log4j-bom/2.17.1/log4j-bom-2.17.1.pom
repo/org/apache/logging/log4j/log4j-bom/2.17.1/log4j-bom-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j/2.17.1/log4j-2.17.1.pom.sha1
repo/org/apache/logging/log4j/log4j/2.17.1/log4j-2.17.1.pom
repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1

What version does the scanner say its found?

John


On Mon, 28 Feb 2022 at 23:15, Juraj Veverka
 wrote:

> Hi David
>
> Just for clarification: we are not relying on the maven dependency plugin
> at runtime. Our runtime is perfectly clear of log4j vulnerabilities.
> The problem is that our security scanners are scanning gitlab runner nodes
> (virtual machines on which we compile and package our application) and
> log4j vulnerability is found there.
>
> Kind regards
> Juraj Veverka
>
> On Mon, Feb 28, 2022 at 1:32 PM Juraj Veverka <
> juraj.veve...@globallogic.com>
> wrote:
>
> > Hi David
> >
> > Many thanks for your email, I really appreciate your reply. This is an
> > isolated example of the problem.
> > https://github.com/jveverka/mvn-dependency-log4j
> > You can find all repro steps there. In case of any questions, feel free
> > to contact me.
> >
> > Kind regards
> > Juraj Veverka
> >
> >
> >
> > On Mon, Feb 28, 2022 at 12:14 PM David Milet 
> > wrote:
> >
> >> Where I work we decided to address log4j vulnerabilities only for
> >> components directly used by the application and actually performing
> logging.
> >> We ignored transitive dependencies and maven plug-ins.
> >> I’m curious about this use case from Venu though, what application would
> >> rely on the maven dependency plugin at runtime? Does it mean you’re
> pulling
> >> maven dependencies after application startup?
> >>
> >> > On Feb 28, 2022, at 03:30, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Please provide more information, like plugin, mven, os version.
> >> >
> >> > We also need an example project which reproduces your issue.
> >> > When we can't reproduce we can't help.
> >> >
> >> > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> >> >  napisał(a):
> >> >
> >> >> Hi team,
> >> >>
> >> >> Can I expect any response?  Is this the right email address for my
> >> >> question?
> >> >>
> >> >> Thanks,
> >> >> Venu
> >> >>
> >> >>
> >> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> >> >>> jaladi.venumad...@verizon.com> wrote:
> >> >>>
> >> >>> Hi team,
> >> >>>
> >> >>> We are using the Maven Dependency Plugin in one of our projects and
> >> our
> >> >>> scanning tools are showing multiple vulnerabilities related to Log4j
> >> >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> >> >>> CVE-2022-23307 and CVE-2021-4104).
> >> >>>
> >> >>> We would  like to know if there are any plans to release a newer
> >> version
> >> >>> of Maven Dependency Plugin with the fixes of these
> >> >>> vulnerabilities(referring to the latest version of Log4j libraries).
> >> If
> >> >>> so, is there any planned date for this release?
> >> >>>
> >> >>> Please let us know any any more information is required.
> >> >>>
> >> >>> Thanks,
> >> >>> Venu
> >> >>>
> >> >>
> >> >
> >> >
> >> > --
> >> > Sławomir Jaranowski
> >>
> >>
> >
> > --
> >
> > Best Regards
> >
> >
> > --
> >
> > Juraj Veverka  | Solution Design Architect
> >
> > M +421 917 521 285
> >
> > www.globallogic.sk  
> >
> >    [image: GLTwitter]
> > 
> > 
> > 
> > 
> >
> > 

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Juraj Veverka]

Hi David

Just for clarification: we are not relying on the maven dependency plugin
at runtime. Our runtime is perfectly clear of log4j vulnerabilities.
The problem is that our security scanners are scanning gitlab runner nodes
(virtual machines on which we compile and package our application) and
log4j vulnerability is found there.

Kind regards
Juraj Veverka

On Mon, Feb 28, 2022 at 1:32 PM Juraj Veverka 
wrote:

> Hi David
>
> Many thanks for your email, I really appreciate your reply. This is an
> isolated example of the problem.
> https://github.com/jveverka/mvn-dependency-log4j
> You can find all repro steps there. In case of any questions, feel free
> to contact me.
>
> Kind regards
> Juraj Veverka
>
>
>
> On Mon, Feb 28, 2022 at 12:14 PM David Milet 
> wrote:
>
>> Where I work we decided to address log4j vulnerabilities only for
>> components directly used by the application and actually performing logging.
>> We ignored transitive dependencies and maven plug-ins.
>> I’m curious about this use case from Venu though, what application would
>> rely on the maven dependency plugin at runtime? Does it mean you’re pulling
>> maven dependencies after application startup?
>>
>> > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
>> wrote:
>> >
>> > Hi,
>> >
>> > Please provide more information, like plugin, mven, os version.
>> >
>> > We also need an example project which reproduces your issue.
>> > When we can't reproduce we can't help.
>> >
>> > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
>> >  napisał(a):
>> >
>> >> Hi team,
>> >>
>> >> Can I expect any response?  Is this the right email address for my
>> >> question?
>> >>
>> >> Thanks,
>> >> Venu
>> >>
>> >>
>> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
>> >>> jaladi.venumad...@verizon.com> wrote:
>> >>>
>> >>> Hi team,
>> >>>
>> >>> We are using the Maven Dependency Plugin in one of our projects and
>> our
>> >>> scanning tools are showing multiple vulnerabilities related to Log4j
>> >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
>> >>> CVE-2022-23307 and CVE-2021-4104).
>> >>>
>> >>> We would  like to know if there are any plans to release a newer
>> version
>> >>> of Maven Dependency Plugin with the fixes of these
>> >>> vulnerabilities(referring to the latest version of Log4j libraries).
>> If
>> >>> so, is there any planned date for this release?
>> >>>
>> >>> Please let us know any any more information is required.
>> >>>
>> >>> Thanks,
>> >>> Venu
>> >>>
>> >>
>> >
>> >
>> > --
>> > Sławomir Jaranowski
>>
>>
>
> --
>
> Best Regards
>
>
> --
>
> Juraj Veverka  | Solution Design Architect
>
> M +421 917 521 285
>
> www.globallogic.sk  
>
>    [image: GLTwitter]
> 
> 
> 
> 
>
> http://www.globallogic.com/Disclaimer.htm
>
>
>

-- 

Best Regards


--

Juraj Veverka  | Solution Design Architect

M +421 917 521 285

www.globallogic.sk  

   [image: GLTwitter]





http://www.globallogic.com/Disclaimer.htm

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Enrico Olivelli]

Juraj,
I have run this command on your reproducer and in "tmp" I cannot find
log4j versions other then 2.17.1

mvn clean install -X -Dmaven.repo.local=tmp > out.txt

Enrico

Il giorno lun 28 feb 2022 alle ore 13:52 Juraj Veverka
 ha scritto:
>
> Hi David
>
> Many thanks for your email, I really appreciate your reply. This is an
> isolated example of the problem.
> https://github.com/jveverka/mvn-dependency-log4j
> You can find all repro steps there. In case of any questions, feel free
> to contact me.
>
> Kind regards
> Juraj Veverka
>
>
>
> On Mon, Feb 28, 2022 at 12:14 PM David Milet  wrote:
>
> > Where I work we decided to address log4j vulnerabilities only for
> > components directly used by the application and actually performing logging.
> > We ignored transitive dependencies and maven plug-ins.
> > I’m curious about this use case from Venu though, what application would
> > rely on the maven dependency plugin at runtime? Does it mean you’re pulling
> > maven dependencies after application startup?
> >
> > > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
> > wrote:
> > >
> > > Hi,
> > >
> > > Please provide more information, like plugin, mven, os version.
> > >
> > > We also need an example project which reproduces your issue.
> > > When we can't reproduce we can't help.
> > >
> > > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> > >  napisał(a):
> > >
> > >> Hi team,
> > >>
> > >> Can I expect any response?  Is this the right email address for my
> > >> question?
> > >>
> > >> Thanks,
> > >> Venu
> > >>
> > >>
> > >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> > >>> jaladi.venumad...@verizon.com> wrote:
> > >>>
> > >>> Hi team,
> > >>>
> > >>> We are using the Maven Dependency Plugin in one of our projects and our
> > >>> scanning tools are showing multiple vulnerabilities related to Log4j
> > >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> > >>> CVE-2022-23307 and CVE-2021-4104).
> > >>>
> > >>> We would  like to know if there are any plans to release a newer
> > version
> > >>> of Maven Dependency Plugin with the fixes of these
> > >>> vulnerabilities(referring to the latest version of Log4j libraries).
> > If
> > >>> so, is there any planned date for this release?
> > >>>
> > >>> Please let us know any any more information is required.
> > >>>
> > >>> Thanks,
> > >>> Venu
> > >>>
> > >>
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> >
>
> --
>
> Best Regards
>
>
> --
>
> Juraj Veverka  | Solution Design Architect
>
> M +421 917 521 285
>
> www.globallogic.sk  
>
>    [image: GLTwitter]
> 
> 
> 
> 
>
> http://www.globallogic.com/Disclaimer.htm

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Juraj Veverka]

Hi David

Many thanks for your email, I really appreciate your reply. This is an
isolated example of the problem.
https://github.com/jveverka/mvn-dependency-log4j
You can find all repro steps there. In case of any questions, feel free
to contact me.

Kind regards
Juraj Veverka



On Mon, Feb 28, 2022 at 12:14 PM David Milet  wrote:

> Where I work we decided to address log4j vulnerabilities only for
> components directly used by the application and actually performing logging.
> We ignored transitive dependencies and maven plug-ins.
> I’m curious about this use case from Venu though, what application would
> rely on the maven dependency plugin at runtime? Does it mean you’re pulling
> maven dependencies after application startup?
>
> > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
> wrote:
> >
> > Hi,
> >
> > Please provide more information, like plugin, mven, os version.
> >
> > We also need an example project which reproduces your issue.
> > When we can't reproduce we can't help.
> >
> > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> >  napisał(a):
> >
> >> Hi team,
> >>
> >> Can I expect any response?  Is this the right email address for my
> >> question?
> >>
> >> Thanks,
> >> Venu
> >>
> >>
> >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> >>> jaladi.venumad...@verizon.com> wrote:
> >>>
> >>> Hi team,
> >>>
> >>> We are using the Maven Dependency Plugin in one of our projects and our
> >>> scanning tools are showing multiple vulnerabilities related to Log4j
> >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> >>> CVE-2022-23307 and CVE-2021-4104).
> >>>
> >>> We would  like to know if there are any plans to release a newer
> version
> >>> of Maven Dependency Plugin with the fixes of these
> >>> vulnerabilities(referring to the latest version of Log4j libraries).
> If
> >>> so, is there any planned date for this release?
> >>>
> >>> Please let us know any any more information is required.
> >>>
> >>> Thanks,
> >>> Venu
> >>>
> >>
> >
> >
> > --
> > Sławomir Jaranowski
>
>

-- 

Best Regards


--

Juraj Veverka  | Solution Design Architect

M +421 917 521 285

www.globallogic.sk  

   [image: GLTwitter]





http://www.globallogic.com/Disclaimer.htm

Re: Maven Dependency Plugin - Log4j vulnerabilities

[David Milet]

Where I work we decided to address log4j vulnerabilities only for components 
directly used by the application and actually performing logging.
We ignored transitive dependencies and maven plug-ins.
I’m curious about this use case from Venu though, what application would rely 
on the maven dependency plugin at runtime? Does it mean you’re pulling maven 
dependencies after application startup? 

> On Feb 28, 2022, at 03:30, Slawomir Jaranowski  wrote:
> 
> Hi,
> 
> Please provide more information, like plugin, mven, os version.
> 
> We also need an example project which reproduces your issue.
> When we can't reproduce we can't help.
> 
> pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
>  napisał(a):
> 
>> Hi team,
>> 
>> Can I expect any response?  Is this the right email address for my
>> question?
>> 
>> Thanks,
>> Venu
>> 
>> 
>>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
>>> jaladi.venumad...@verizon.com> wrote:
>>> 
>>> Hi team,
>>> 
>>> We are using the Maven Dependency Plugin in one of our projects and our
>>> scanning tools are showing multiple vulnerabilities related to Log4j
>>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
>>> CVE-2022-23307 and CVE-2021-4104).
>>> 
>>> We would  like to know if there are any plans to release a newer version
>>> of Maven Dependency Plugin with the fixes of these
>>> vulnerabilities(referring to the latest version of Log4j libraries).  If
>>> so, is there any planned date for this release?
>>> 
>>> Please let us know any any more information is required.
>>> 
>>> Thanks,
>>> Venu
>>> 
>> 
> 
> 
> -- 
> Sławomir Jaranowski

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Slawomir Jaranowski]

Hi,

Please provide more information, like plugin, mven, os version.

We also need an example project which reproduces your issue.
When we can't reproduce we can't help.

pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
 napisał(a):

> Hi team,
>
> Can I expect any response?  Is this the right email address for my
> question?
>
> Thanks,
> Venu
>
>
> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> jaladi.venumad...@verizon.com> wrote:
>
> > Hi team,
> >
> > We are using the Maven Dependency Plugin in one of our projects and our
> > scanning tools are showing multiple vulnerabilities related to Log4j
> > (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> > CVE-2022-23307 and CVE-2021-4104).
> >
> > We would  like to know if there are any plans to release a newer version
> > of Maven Dependency Plugin with the fixes of these
> > vulnerabilities(referring to the latest version of Log4j libraries).  If
> > so, is there any planned date for this release?
> >
> > Please let us know any any more information is required.
> >
> > Thanks,
> > Venu
> >
>


-- 
Sławomir Jaranowski