[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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)
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/).
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
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 :-).
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)?
Thanks,
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