Ed,
thank you for the detailed analysis. I guess you’re right:
determining the real exposure of each one of the plugins and features
when it comes to such a central component like Log4J is really
challenging.
The good thing though is that, like you already showed, the risk
seems to be contained into only in 1 package (org.apache.log4j.net)
and only a bunch of plugins seem to include a (non-greedy) dependency
to that package. I like the idea of removing that package from future
version of “org.apache.log4j” but I have to admin I can’t really
assess what that actually means in terms of effort and consequences.
Anyway, I just wanted to use the momentum to try and dig a bit deeper
and to preemptively search for similar issues that might arise in the
future :)
Regards,
Federico
*From:*cross-project-issues-dev
<cross-project-issues-dev-bounces@xxxxxxxxxxx> *On Behalf Of *Ed Merks
*Sent:* Tuesday, December 14, 2021 10:36 AM
*To:* cross-project-issues-dev@xxxxxxxxxxx
*Subject:* Re: [cross-project-issues-dev] [orbit-dev] log4j
vulnerability in Eclipse?
Jeane,
The following is not saying your suggestion is a bad idea, but rather
to clarify the nature of what we will need to say and do...
Eliminating the use of org.apache.log4j quickly seems unpromising at
best.
At least superficially we might as well list all projects as affected.
Just looking at the first two dependencies:
And then following the dependencies of second of those:
We see that pretty close to the entire universe of Eclipse plugins is
downstream from these.
And then, we don't know for a fact that anyone actually creates an
org.apache.log4j.net.SocketServer...
Looking more closely at the nature of the dependencies though, it
appears that org.apache.commons.logging only depends on the
org.apache.log4j package:
And then it's only an optional, non-greedy dependency:
Nothing (on the release train) depends on the org.apache.log4j.net
package where the offending class is located:
In the end, determining whether there is an actual risk rather than a
hypothetical risk challenging at best. I expect that everyone (and I
do mean literally everyone using this bundle) is just doing this and
has zero risk:
private static final Logger log = Logger.getLogger(<SomeClass>class);
Perhaps we could create a new version of org.apache.log4j that
removes the org.apache.log4j.net.SocketServer class (or the entire
package), as a crude quick fix, but even that would require some IUs
to relax/modify their bounds:
This site suggests there is a 1.2.18 version of log4j though
elsewhere it I saw a statement that the problem would not be fixed.
https://www.whitesourcesoftware.com/vulnerability-database/CVE-2019-17571
Accurate information is hard to come by...
Regards,
Ed
On 14.12.2021 09:42, Jeanne, Federico wrote:
Denis,
good idea with the page, I think it brings a nice overview of
what has been investigated and how deep the vulnerability reached.
I couldn’t help noticing though that some of the listed projects
mentioned using Log4j 1.2.15. Wouldn’t it also make sense to have
another page to address the vulnerability CVE-2019-17571 (the one
Jonah mentioned)?
Regards,
Federico
*From:*cross-project-issues-dev
<cross-project-issues-dev-bounces@xxxxxxxxxxx>
<mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx> *On Behalf
Of *Denis Roy
*Sent:* Monday, December 13, 2021 10:46 PM
*To:* cross-project-issues-dev@xxxxxxxxxxx
*Subject:* Re: [cross-project-issues-dev] [orbit-dev] log4j
vulnerability in Eclipse?
I am going to crowd-source this. I need everyone to chime in on
this Wiki page:
https://wiki.eclipse.org/Eclipse_and_log4j2_vulnerability_(CVE-2021-44228)
<https://wiki.eclipse.org/Eclipse_and_log4j2_vulnerability_(CVE-2021-44228)>
I will see that this information gets broadcast tomorrow, once
there is some information in the table.
Denis
On 2021-12-13 15:03, Jonah Graham wrote:
Denis,
It is the log4j vulnerability, the fact that it doesn't
affect some versions of log4j is in the vulnerability
description. Please continue doing this - I appreciate it.
Most media reports call it simply log4j - but you can reduce
the noise by calling it "Eclipse and log4j2 vulnerability
(CVE-2021-44228)"
Ed,
I am delighted that we are dependent on a version of log4j
that doesn't have this problem - but I wouldn't get too
excited about promoting that Eclipse IDE hasn't updated a
dependency. log4j 1.2 has been EOL for 6+ years
(https://logging.apache.org/log4j/1.2/
<https://logging.apache.org/log4j/1.2/>). I am glad this
vulnerability doesn't exist, but log4j 1.2 does have its own
problems - like CVE-2019-17571 - so nothing to get too
excited about.
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>
On Mon, 13 Dec 2021 at 14:50, Denis Roy
<denis.roy@xxxxxxxxxxxxxxxxxxxxxx
<mailto:denis.roy@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
IANAD so perhaps I'm the worst possible person to be
doing this.
On 2021-12-13 14:47, Ed Willink wrote:
Hi
Maybe the CVE is also misleading or the discussion
here is very wrong. The current Orbit repo contains
org.apache.log4j 1.2.15 is clearly not log4j2. It has
been in use unchanged in every Eclipse distribution
for at least the last ten years.
The analysis on this thread has been about
org.apache.logging.log4j which could be a log4j2. It
is unused in core and many Eclipse configurations.
Please be precise.
Regards
Ed Willink
On 13/12/2021 19:33, Denis Roy wrote:
The CVE shows: Apache Log4j2
I would assume that is correct.
On 2021-12-13 14:31, Ed Willink wrote:
Hi
Please start by correctly referencing the
vulnerability.
It is with org.apache.logging.log4j,
There is no issue with org.apache.log4j so
continually referring to this as a log4j
vulnerability is very misleading.
AFAICT no Eclipse installation of mine has
ever included org.apache.logging.log4j.
Regards
Ed Willink
On 13/12/2021 19:15, Denis Roy wrote:
How about I start:
title: *Eclipse and log4j vulnerability
(CVE-2021-442280)*
Here is the status of the various Eclipse
Foundation projects, with regards to
CVE-2021-442280:
- Eclipse IDE 2021-12: *not vulnerable*
- Eclipse Jetty (version): status
- Eclipse GlassFish (version): status
- Eclipse jGit (version): status
We would likely need to get the input
from other projects, to "self-certify".
I can do this by reaching out to
eclipse.org-committers if anyone agrees.
At this point, most of Europe is logged
out for the day, and time is ticking away
fast for this sort of action.
Denis
On 2021-12-13 14:00, Jonah Graham wrote:
Hi Denis,
Yes - that seems best. I can help
with the actual story - as can others
on this list (I hope :-).
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
<http://www.kichwacoders.com>
On Mon, 13 Dec 2021 at 13:58, Denis
Roy <denis.roy@xxxxxxxxxxxxxxxxxxxxxx
<mailto:denis.roy@xxxxxxxxxxxxxxxxxxxxxx>>
wrote:
Good question.
If we agree on a story (ie, if
someone can help me write what
the actual story is), I can
certainly post a blog post on the
blogs.eclipse.org
<http://blogs.eclipse.org>domain.
From there, we could tweet about
it from the official @EclipseFdn
twitter account, and perhaps add
links to the post from the
Newcomers forum.
Does that seem acceptable?
Denis
On 2021-12-13 13:44, Jonah Graham
wrote:
Thanks everyone for working
on this - I think we have a
pretty good story now about
what the Eclipse IDE / SimRel
has done for the log4j
vulnerability.
The last thing is to say so
in a concise way - where
can/should we say so (besides
this mailing list)?
Thanks,
Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
<http://www.kichwacoders.com>
On Mon, 13 Dec 2021 at 12:58,
Ed Merks <ed.merks@xxxxxxxxx
<mailto:ed.merks@xxxxxxxxx>>
wrote:
Christoph,
I really appreciate your
creative ideas. I think
"we, i.e., as an I"
should indeed plan long
term for the possibility
of expedient mitigation
of such problems in the
future using this type of
approach.
For the project catalogs
I've regenerated them
such than installing any
version of the RCP
package (with any
installer) will install
the latest
version of Passage which
strictly requires the
updated/fix version of
org.apache.logging.log4j.
Also any
installer-created RCP
package
installation will ask to
update itself upon
startup/restart.
https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=929d140afc34ecdb85b7996c63ce0b36b6723a34
<https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=929d140afc34ecdb85b7996c63ce0b36b6723a34>
Another thought I had is
that the donation support
I've added opens a
browser page. In this
case we could change the
URL such that a page
with information about
this CVE could be
presented...
But now it's late in the
day and I'm done for now.
Regards,
Ed
On 13.12.2021 18:03,
Christoph Läubrich wrote:
> Hi Ed,
>
> > One problem is we
don't know all the things
that strictly require the
> > older bundle.
>
> In the end what matters
is that the bundle is no
longer available. If
> we don't uninstall them
at laes they won't
resolve anymore and people
> will go to the project
website, report an issue
and/or install an
> update :-)
>
> > In the end it at the
simplest, it could just
be a feature with p2.inf
> > with negative
requirements for bundles
that have been determined
to be
> > unsafe.
>
> yep that's what I have
had in mind, I think it
would be cool to have
> one global feature "CVE
Mitigation" or something
and this
> requires/includes
individual CVE features
that ship with appropriate
> p2.inf items.
> Thus way, once added to
an IDE this will enable
us to make CVE fixes
> available tor a broad
audience and make people
more aware of them
> through the update
capabilities of eclipse
itself.
>
> >> What do you think
does this sounds reasonable?
> > It's a creative
idea. I like it.
>
> Good to hear! As you
probably know much more
about p2.inf magic than
> me can you craft such a
feature so we can
investigate this more? As
> mentioned before this
is more an idea so I
can't shar any concrete
> code samples yet and
have no idea where this
would bes be placed (part
> of the platform cbi?
github/gitlab project
under eclipse umbrella?
> eclipse cbi maybe?)
>
>
> Am 13.12.21 um 17:48
schrieb Ed Merks:
>> Christoph,
>>
>> Comments below.
>>
>> On 13.12.2021 17:29,
Christoph Läubrich wrote:
>>> Hi Ed,
>>>
>>> I wonder if it would
not be possible to
publish a general purpose
>>> "CVE mitigation"
Updatesite everyone could
add to an existing
>>> eclipse install.
>> Of course not everyone
has Passage installed,
nor this specific
>> bundle...
>>>
>>> Such an Updatesite
could contain a Unit for
a given CVE (e.g.
>>> CVE-2021-44228 in
this case) that defines a
negative requirement on
>>> any affected version
(in this case any
org.apache.logging.log4j
with
>>> version range < 2.15).
>> Yes that's
theoretically possible.
(And in the catalog I can
easily
>> do this, but not all
installation are
installed from the catalog.)
>>>
>>> What will happen then
is that P2 will give the
user the choice to
>>> install this
mitigation unit and uninstall
>> P2 generally wants to
install features so such
a thing would need to
>> be packaged up as a
feature...
>>>
>>> a) the dangerous bundle
>>> b) any dependent and
affected unit (passage in
this case)
>>>
>>> from the current IDE.
>> One problem is we
don't know all the things
that strictly require the
>> older bundle. The
parts of Passage
contributed to the train
only
>> have lower bounds, but
there are Passage
features that include this
>> bundle with an exact
range...
>>>
>>> Once an Update is in
place, passage could be
installed (e.g. with a
>>> separate update-site)
again including a fixed
version of the
>>> problematic dependecy.
>>>
>> Another question is
what else out there that
might already be
>> installed depend on
logging.log4j and would
also need to be updated
>> or uninstalled? That's
an open ended question...
>>> Even though such a
site would currently need
some kind of
>>> handcrafted metadata,
we could enhance this so
we probably once have
>>> some automatic import
of CVE from public
databases and automatic
>>> notification of users
about new CVE affecting
their IDE.
>>>
>> Yes, such a thing will
follow some pattern so
generating such a thing
>> would be good...
>>> Including such a site
in a target platform of a
build could
>>> effectively fail the
build (and make projects
automatically aware of
>>> new problems) as they
arise, also preventing
one from including
>>> problematic
dependencies in the future.
>> In the end it at the
simplest, it could just
be a feature with p2.inf
>> with negative
requirements for bundles
that have been determined to
>> be unsafe.
>>> What do you think
does this sounds reasonable?
>> It's a creative idea.
I like it.
>>> Am 12.12.21 um 14:07
schrieb Ed Merks:
>>>> Alexander,
>>>>
>>>> Will you set the
lower bound to force the
fixed version and to
>>>> disallow the older
version?
>>>>
>>>> If only the
installer and its product
catalogs were involved, I
>>>> could fix the
problem easily by adding
an update site and forcing
>>>> the version range to
install the fixed
version. I wouldn't even
>>>> need a new version
of Passage to force/fix
that...
>>>>
>>>> But we're also
talking about the release
train repository, which
>>>> would need a respin.
Unfortunately there are
updates in the SimRel
>>>> repo after the
2021-12 tag:
>>>>
>>>> Some of those will
be needed because the
>>>>
https://download.eclipse.org/eclipse/updates/4.22-I-builds
<https://download.eclipse.org/eclipse/updates/4.22-I-builds>
>>>> repository is gone.
Hopefully other projects
contributed stable
>>>> repositories with
unchanging released
content rather than pointing
>>>> at "moving target"
that has changed its
content since the release.
>>>>
>>>> If we decide we need
to do a respin and we
accomplish that, then
>>>> EPP needs to respin
as well. This will be
something the Planning
>>>> Council will need to
discuss and to decide
which actions to take.
>>>>
>>>> Only you know how
Passage uses the logging
facility to know if
>>>> there is in actual
fact a risk. I.e., is
Passage actually logging
>>>> information obtained
from an internet
connection and is that
>>>> actually
enabled/activated in the
RCP/RAP package itself?
I.e.,
>>>> does what Jens
Lideström outlined
apply? (Thanks Jens!)
If not,
>>>> then perhaps we're
unduly alarmed. I could
see nothing that
>>>> appears to be
related to Passage in an
IDE into which I installed
>>>> Passage, i.e., no
preferences, no wizards,
no views, nothing
>>>> obvious. Is it
perhaps the case that the
security problems would
>>>> only manifest
themselves in
applications where
Passage is deployed
>>>> at runtime for
licensing control of that
application?
>>>>
>>>> Please try to
outline the risk factors
of Passage's development
>>>> tools being
installed in a IDE
application to help
inform the
>>>> Planning Council in
making a decision.
>>>>
>>>> P.S., Passage in the
only component on the
2021-12 train that is
>>>> affected; I cannot
comment on all
Eclipse-distributed
content in
>>>> general...
>>>>
>>>> Regards,
>>>> Ed
>>>>
>>>> On 12.12.2021 11:04,
Alexander Fedorov wrote:
>>>>> Passage Team is
working to provide
Eclipse Passage 2.2.1
that will
>>>>> consume fixed
logger from
>>>>>
https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository
<https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository>
>>>>>
>>>>>
>>>>> Ed, how could we
then provide an update
for released SimRel 2021-12?
>>>>>
>>>>> Regards,
>>>>> AF
>>>>>
>>>>> P.S. I'm really
surprised to have the
only component affected
>>>>> after having
org.apache.*logging**.log4j
2.8.2 *published in
>>>>> Eclipse Orbit
starting from 2020-09 (6
releases).
>>>>>
>>>>>
>>>>>
>>>>> 12/12/2021 12:41
PM, Ed Merks пишет:
>>>>>>
>>>>>> Just to avoid any
confusion such as that
which Ed Willink
>>>>>> mentioned, the
>>>>>>
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228>
>>>>>> issue is
specifically about the class
>>>>>>
org.apache.logging.log4j.core/lookup.JndiLookup.which
is not in a
>>>>>> package provided
by org.apache.*log4j *but
rather in a package
>>>>>> provided by
org.apache.*logging**.log4j
*as illustrated here in a
>>>>>> CBI p2 aggregator
repo view:
>>>>>>
>>>>>> Based on the
analysis tool I've been
developing for better
>>>>>> managing SimRel,
e.g., to provide
traceability and dependency
>>>>>> analysis, it's
definitely the case that
only Passage depends on
>>>>>> this bundle:
>>>>>>
>>>>>>
>>>>>> Specifically via
bundle requirements (as
opposed to package
>>>>>> requirements):
>>>>>>
>>>>>>
>>>>>> Those requirements
have no upper bound, only
an inclusive lower
>>>>>> bound, such that
they will resolve and use
any higher version of
>>>>>>
org.apache.logging.log4j.
As such, installing
Passage with
>>>>>>
https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository
<https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository>
>>>>>> in the available
sites and enabling to use
those, does install
>>>>>> the newer version:
>>>>>>
>>>>>>
>>>>>> The bad news is
that the RCP/RAP package
contains Passage and
>>>>>> hence the bad
version of the
org.apache.logging.log4j
bundle.
>>>>>>
>>>>>> What's not clear
is whether Passage
actually logs messages whose
>>>>>> content can be
externally
subverted/exploited via
contact to the
>>>>>> web and whether
such actions are activity
is actually enabled by
>>>>>> default, e.g., in
the RCP/RAP package...
>>>>>>
>>>>>> Regards,
>>>>>> Ed
>>>>>>
>>>>>>
>>>>>> On 11.12.2021
20:48, Gunnar Wagenknecht
wrote:
>>>>>>> Thanks Matthias!
>>>>>>>
>>>>>>> According to Wayne, 2.15 has already been vetted and is good for
>>>>>>> use:
>>>>>>> https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html
<https://www.eclipse.org/lists/eclipse.org-committers/msg01333.html>
>>>>>>>
>>>>>>> -Gunnar
>>>>>>>
>>>>>>> --
>>>>>>> Gunnar Wagenknecht
>>>>>>> gunnar@xxxxxxxxxxxxxxx
<mailto:gunnar@xxxxxxxxxxxxxxx>,
http://guw.io/
<http://guw.io/>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 11, 2021, at 20:36, Matthias Sohn
>>>>>>>> <matthias.sohn@xxxxxxxxx
<mailto:matthias.sohn@xxxxxxxxx>>
wrote:
>>>>>>>>
>>>>>>>> On Sat, Dec 11, 2021 at 11:35 AM Gunnar Wagenknecht
>>>>>>>> <gunnar@xxxxxxxxxxxxxxx
<mailto:gunnar@xxxxxxxxxxxxxxx>>
wrote:
>>>>>>>>
>>>>>>>> Alexander,
>>>>>>>>
>>>>>>>>> On Dec 11, 2021, at 10:16, Alexander Fedorov
>>>>>>>>> <alexander.fedorov@xxxxxxxxxx
<mailto:alexander.fedorov@xxxxxxxxxx>>
wrote:
>>>>>>>>> It would be great to learn vulnerability clean-up
process
>>>>>>>>> with
>>>>>>>>> Eclipse Orbit team to then apply it to Eclipse Passage.
>>>>>>>>
>>>>>>>>
>>>>>>>> There is no Orbit team. Orbit is driven by project committers
>>>>>>>> using/needing libraries in Orbit.
>>>>>>>> I encourage the Eclipse Passage project to submit a Gerrit
>>>>>>>> review for a newer version.
>>>>>>>>
>>>>>>>>
>>>>>>>> considering the buzz around this vulnerability I went
ahead and
>>>>>>>> pushed an update to log4j 2.15 for orbit
>>>>>>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768
<https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768>
>>>>>>>> note that the required clearlydefined score
isn't reached yet,
>>>>>>>> if this doesn't change soon
>>>>>>>> maybe someone can contribute the missing information to
>>>>>>>> clearlydefined or
>>>>>>>> we file CQs to get the license approval for the new version
>>>>>>>>
>>>>>>>> You can also try a new way as described by Mickael here:
>>>>>>>> https://www.eclipse.org/lists/orbit-dev/msg05509.html
<https://www.eclipse.org/lists/orbit-dev/msg05509.html>
>>>>>>>>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx <mailto:cross-project-issues-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev <https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>
--
*Denis Roy*
*Director, IT Services | **Eclipse Foundation*
/Eclipse Foundation/ <http://www.eclipse.org/>/: The Community
for Open Innovation and Collaboration/
Twitter: @droy_eclipse
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
