| Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse? |
Alexander,
Thank you for the analysis and sorry that your component is the center of such negative attention through not fault of your own...
I looked at how Passage is using the logging facilities, using your Oomph setup for provisioning an IDE. Attached are the search results of all the places where content is logged.
Based on this, the primary concern would be if the message text of an exception included an offensive string such as ${jndi:ldap://127.0.0.1/a}. I expect that more than a little creativity would be involved to exploit that given an attacker would need to coerce the client to visit sites it would not generally visit on its own, or do some kind of man-in-the-middle attack to intercept a legitimate site accessed via a non-secure protocol, and then likely the URL itself would need to contain such a string for it to end up in the exception message. It's quite far fetched, but as you say, time and creativity conquers all...
Certainly clients using the Passage runtime for past releases and for the 2021-12 release (the Passage 2.2.0 release) should upgrade to the Passage 2.2.1 release:
https://download.eclipse.org/passage/drops/release/2.2.1-R
My sense though is that there is no (significant) risk in a tooling environment, i.e., in a running RCP/RAP IDE package.
Does the above seem like a fair and reasonable assessment?
Regards,
Ed
On 12.12.2021 17:22, Alexander Fedorov wrote:
Ed,
Eclipse Passage 2.2.1 is published at https://download.eclipse.org/passage/updates/release/2.2.1/ldc/,
> Will you set the lower bound to force the fixed version and to disallow the older version?
yes, org.apache.logging.log4j;bundle-version="2.15.0"
> 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?
Nothing during scenarios that are activated for "host" RCP/RAP package. Currently Passage just creates the plug-in projects with license checks configured, using standard PDE facilities
> 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.
Thank you for feedback, Passage has "Welcome" entries and PDE wizards for "Create RCP + UI" mode, but it definitely needs to be more discoverable. The fresh request we have is to support Market Place Client with license checks before installation and this is pretty doable with the sufficient p2 metadata published.
> 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?
Yes, theoretically, security problems can be caused by a very skilled attacker for runtime instances of user-created applications where license check will be triggered.
No idea how robust the org.apache.logging.log4j.core/lookup.JndiLookup class is, but if we assume that logged data could realize the threat - it becomes a matter of time and creativity.
Regards,
AF
12/12/2021 4:07 PM, 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:
-Gunnar
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 orbitnote that the required clearlydefined score isn't reached yet, if this doesn't change soonmaybe someone can contribute the missing information to clearlydefined orwe file CQs to get the license approval for the new version_______________________________________________You can also try a new way as described by Mickael here:
-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, 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
_______________________________________________ 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
