[
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?
|
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