I did a bit more investigation. The class
org.apache.log4j.net.SocketServer, although it has a
public constructor is effectively useless because it
has no public methods. Its intended use is via a
call to org.apache.log4j.net.SocketServer.main which
starts a thread and then runs an infinite loop that's
terminated only by an exception; the thread it starts
runs org.apache.log4j.net.SocketNode which is the
thing that reads from a socket and causes the
exposure. Fortunately nothing in the library calls
this class' main. Furthermore I don't believe there
is a sensible use case for this utility class within
an IDE or an RCP application, i.e., it think it's safe
to assume that no one calls this class; it's
definitely not something that is implicitly started
like the JNDI lookup.
I suppose projects could confirm (explicitly state)
that indeed they don't call this particular class and
hence do not expose this vulnerability.
Perhaps that information could be captured in the
same table instead of a separate table, so that it
covers both "log4j" issues. E.g., the table could
say:
Just a thought. We could also do a separate table
initialized via copy and paste.
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
_______________________________________________
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