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