| Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse? |
_______________________________________________Frederico,
I do not mind starting a second page -- asking all projects (via the eclipse.org-committers mailing list) to self-assess and post status to the page is another thing.
I am hoping, however, that moving forward, we can start to provide such a service to our users: when a severe vulnerability is present in a popular dependency, that all projects can self-asses and report back on a single page, so that our users, adopters, integrators can all have the full story about the impact on our projects.
In the case of the "old" log4j vulnerability: I don't understand the vulnerability, but if consensus is that is it worth repeating the exercise of creating the page and soliciting input, then I will take it on. Please all, chime in.
Also: we are being asked if Eclipse is vulnerable to log4shell? What would the short answer be?
Many thanks,
Denis
On 2021-12-14 08:55, Jeanne, Federico wrote:
Ed,
(don’t worry about the mix-up with the names, you’re definitely not the first one to get confused 😃 )
Thank you again for your detailed analysis, I think it will be very helpful when the time comes for others to assess the severity of the vulnerability on the “old” Log4J !.
- “Perhaps that information could be captured in the same table instead of a separate table, so that it covers both "log4j" issues”
I think a separate table (maybe even a separate Wiki Page) would be better. Though similar, they are separate issues.
I’m new to this so I’m not sure how this goes, but would you create the new page/table and ask other maintainers to fill it up just like Denis did? If not, who would? Denis?
Regards,
Federico
From: cross-project-issues-dev <cross-project-issues-dev-bounces@xxxxxxxxxxx> On Behalf Of Ed Merks
Sent: Tuesday, December 14, 2021 2:08 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?
Federico,
(Sorry I messed up first and last names.)
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:
Uses log4j 1.2.15 only and does not use org.apache.log4j.net.SocketServer.
Just a thought. We could also do a separate table initialized via copy and paste.
Regards,
Ed
On 14.12.2021 13:00, Jeanne, Federico wrote:
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
From: cross-project-issues-dev <cross-project-issues-dev-bounces@xxxxxxxxxxx> On Behalf Of Ed Merks
Sent: Tuesday, December 14, 2021 10:36 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: 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,
EdOn 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
From: cross-project-issues-dev <cross-project-issues-dev-bounces@xxxxxxxxxxx> On Behalf Of Denis Roy
Sent: Monday, December 13, 2021 10:46 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: 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
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
On Mon, 13 Dec 2021 at 14:50, Denis Roy <denis.roy@xxxxxxxxxxxxxxxxxxxxxx> wrote:
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 :-).
On Mon, 13 Dec 2021 at 13:58, Denis Roy <denis.roy@xxxxxxxxxxxxxxxxxxxxxx> wrote:
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,
On Mon, 13 Dec 2021 at 12:58, Ed Merks <ed.merks@xxxxxxxxx> wrote:
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 listcross-project-issues-dev@xxxxxxxxxxxTo 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 listcross-project-issues-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxxTo 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
