Bugzilla – Full Text Bug Listing
| Summary: | p2 metadata (even without artifacts) can be an attack vector | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Mickael Istria <mistria> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | akurtakov, eclipse.tjw, Ed.Merks, gunnar, jonah, laeubi, loskutov, tjwatson, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=576705 | ||
| Whiteboard: | |||
|
Description
Mickael Istria
I think this qualifies as a CVE. @Thomas: is it OK? (In reply to Mickael Istria from comment #1) > I think this qualifies as a CVE. > @Thomas: is it OK? Yes I think so. I've marked this committer-only now. I've assigned CVE-2021-41037. Don't use that number externally until after we disclose. What's the status on this? Because of a quirk of the CVE assignment process, we're getting very close to needing to either push the CVE to the central CNA or reassign this CVE to another issue (and then assign another CVE to this issue when you're ready). Unless we have a rush of vulnerability reports, we're probably good until the end of the year. FWIW... we're currently using the old CVE reporting system, but are going to switch over to their new CVE reservation system which will make this sort of timing problem go away. (In reply to Wayne Beaton from comment #5) > What's the status on this? no progress on a solution, and as far as I'm aware of, no plans from anyone to fix it so far. If there's no prospect of this being fixed, then I recommend that we push the CVE sooner rather than later. (In reply to Wayne Beaton from comment #7) > If there's no prospect of this being fixed, then I recommend that we push > the CVE sooner rather than later. I personally have no objection here. However I'm not much familiar with best way to handle security issue, so others' opinions are probably much more valuable. (In reply to Mickael Istria from comment #3) > I've opened https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/124 I've pushed the issue to the central authority. I'm removing the committer-only flag since the issue has been publicly disclosed via the CVE. While there is possibility to "fake" the metadata, I must confess I don't understand how to use that in practice. Just assume I can make a user use my update site and choose something to install I can already do lot more things (e.g. execute arbitrary code by implementing a common extension point that activates my Activator, adding/overriding Menu items, add new buttons or editor/key bindings), this even includes executing any native command or contacting remote sites and as most eclipse ship with SSH support even open reverse SSH sessions... so injecting malicious code into p2 meta-data seems not advantageous. I think the key line is "There is no concept of "trusting" metadata like it exists for artifacts." The trust for metadata comes simply from the transport layer that downloads the metadata (e.g. normally https). A good example in practice is related to why EF just removed loads of listings from the marketplace. They were on http:// or the p2 sites pointed at domains that were no longer registered. Placing artifacts on those (more easily compromiseable) p2 sites would display trust dialog to user, but the metadata/p2/etc would "just happen" I thought p2 disabled usage of http altogether at some point also. (In reply to Thomas Watson from comment #12) > I thought p2 disabled usage of http altogether at some point also. It's only warning: Using unsafe http transport to retrieve http://download.eclipse.org/technology/m2e/releases/, see CVE-2021-41033. Consider using https instead. I think the problem is that if I can make the user to install something, then I'm not need to craft the meta-data in a special way, I can simply make a valid site with a jar signed with an official certificate everyone can buy for a few bucks, or simply depend on users that dismiss warning dialogs anyways.
So just *loading* the meta-data should not cause any issues... and if an attacker is in control of the (content-) metadata I'm lost anyways, p2 currently assumes that one only adds trusted sites, so we can trust the meta-data.
What I can think of (and what would be rather easy to archive) would be that we do it like maven-central does and for each content.xml/jar/xz (same for artifacts.xml/jar/xz) we look for a corresponding content.xml.sha256 and content.xml.asc (one should then also consider p2.index!) and then we can verify the integrity and the origin of the meta-data.
I see the following problems:
- one can always create a valid site, with a PGP Key that looks similar to something "official", even from a site with https-certificate and there is no authority to "proof" validity and if I can make the user to install something it is likely to dismiss warning dialogs
- Still it is common for user to use very old (or even ancient) Eclipse versions (and thus P2 as well) and also Eclipse claims "long-term-compatibility" and we support such users even with providing some software for very old Eclipse, so as long as we do not encourage users to upgrade (e.g. show a big-fat banner after a new release is there that this Eclipse version is outdated and vulnerable to security risks) its likely such enhancements will never get widely adopted.
> It's only warning:
There is even an option to disable the warning because users are annoyed when using local intranet sites :-\
The exact nature of the problem as described in the CVE seems somewhat open to interpretation. E.g., this statement seems kind of "open": As a result, it's possible to install a unit that will run malicious code during installation without user receiving any warning about this installation step being risky when coming from untrusted source. I though the issue was more about "bad things" happening when running the resulting installation not about "bad things" happening while installing, but that aside, given that https://github.com/eclipse-equinox/p2/issues/230 ensures that metadatada is accessed not by http but rather by https, I'm not entirely sure if the fact that it securely comes from a secured source is the same as it coming from a "trusted" source. I think it is the same, but maybe someone else will think it isn't. How to resolve that? I think in the same way we said that artifacts simply coming from https:// isn't sufficient (needs GPG or jarsigning) the same applies to touchpoints. We could solve that by GPG, jarsigning or otherwise signing the p2 metadata. That said, what Christoph said in Comment 14 Paragraph 1 is still very relevant. If you can social engineer the user to add a "bad" p2 site it is very easy to bypass other issues. There is a way to validate jars, but there isn't a way to do that for p2 metadata. What I really struggle to answer is, now with p2#230 done, what priority this remaining issue has. The implementation is one side of things, but rolling this out to all the existing p2 sites will take quite a long time. https only ensures that the communication channel is secure, not that the data is secure! I can buy a valid certificate for only a few bucks so that's not really an issue ... Just out of curiosity eclipse.de is a domain owned by itemis (at least it redirects to their site), eclipse.com is currently not serving any content so probably it is for sale? So would a user not so familiar with the eclipse infrastructure really spot the difference to be a "danger" from https://download.eclipse.org/eclipse/updates/4.24/ versus https://download.eclipse.de/eclipse/updates/4.24/ https://download.eclipse.com/eclipse/updates/4.24/ ... :-) I've opened up this issue as a follow up: https://github.com/eclipse-equinox/p2/issues/235 Resolved via https://github.com/eclipse-equinox/p2/issues/235 |