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
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
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)
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)"
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/). 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.
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.
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 :-).
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 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)?
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
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
>>>>
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
>>>>>
>>>>>
>>>>> 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
>>>>>>
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
>>>>>>
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
>>>>>>>
>>>>>>> -Gunnar
>>>>>>>
>>>>>>> --
>>>>>>> Gunnar Wagenknecht
>>>>>>> gunnar@xxxxxxxxxxxxxxx, http://guw.io/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 11, 2021, at 20:36, Matthias
Sohn
>>>>>>>> <matthias.sohn@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> On Sat, Dec 11, 2021 at 11:35 AM Gunnar
Wagenknecht
>>>>>>>> <gunnar@xxxxxxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> Alexander,
>>>>>>>>
>>>>>>>>> On Dec 11, 2021, at 10:16,
Alexander Fedorov
>>>>>>>>> <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
>>>>>>>> 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
>>>>>>>>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://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, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Denis Roy
Director, IT Services | Eclipse Foundation
Eclipse Foundation: 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, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
