[
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?
|
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
-Gunnar
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/orbit-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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list,
visithttps://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,
visithttps://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,
visithttps://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
_______________________________________________
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
_______________________________________________
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
