Community
Participate
Working Groups
I originally raised this for Tycho at https://github.com/eclipse/tycho/issues/248 and was asked by Mickael Istria to first ask here regarding this. The main point is that downloading artifacts over unencrypted HTTP can allow man-in-the-middle attacks. Recent Maven releases have started blocking artifact downloads over unencrypted HTTP by default. Please have a look at the above mentioned GitHub issue for more information. What is your opinion on this?
People behind firewalls often have problems with https access failing... Also, artifacts have checksums that would prevent successfully tampering the files themselves.
> Also, artifacts have checksums that would prevent successfully tampering the > files themselves. The checksums in metadata can be tamperws as well, and since usually metadata come from the same site as artifacts, checksums are not a reliable source of trust; and they basically never were meant to be used for security,but more to detect transfer issues.
The artifacts generally come from mirrors while the site information comes from the original site, e.g., download.eclipse.org. So whether https is used for the artifacts is somewhat orthogonal to whether https is used to access the metadata. Are we concerned about site tampering as well? Or just network tampering? Because if the https access to download.eclipse.org is safe/secure, then the checksums are also safe/secure. After all, we use checksums for downloads such as this: https://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/2021-06/R/eclipse-java-2021-06-R-win32-x86_64.zip Note that I'm just asking questions and making observations not saying what's right or wrong. This bugzilla specifically mentions artifacts while I think the issue of security is broader than just the artifacts... Also with signing, you can't really tamper signatures can you?
(In reply to Ed Merks from comment #3) > The artifacts generally come from mirrors while the site information comes > from the original site, e.g., download.eclipse.org. I'm thinking about p2 repos in general, not about download.eclipse.org in particular. But if one tries to hack between download.eclipse.org and the user who tries to install (eg acts as a man in the middle that can modify output -thing that should be less possible with https than with http), then they can also tweak the metadata to disable mirrors. Basically, someone who wants to build an attack over p2 installation (inject their own artifacts instead of using reference ones) would be more successful just hacking the metadata and directing p2 to alternative sites and artifacts. Metadata are probably the weakest point of the process. > Are we concerned about site tampering as well? Or just network tampering? > Because if the https access to download.eclipse.org is safe/secure, then the > checksums are also safe/secure. I don't know about site tampering, but if we are concerned about network tampering then I think it's fair to make HTTP disbled by default as suggested by reported. > After all, we use checksums for downloads such as this: > https://www.eclipse.org/downloads/download.php?file=/technology/epp/ > downloads/release/2021-06/R/eclipse-java-2021-06-R-win32-x86_64.zip What makes that checksums can be seen as a security verification approach is that the checksum comes from a source that is supposed to be trusted by user (assuming user trust eclipse.org and https is enough to ensure data integrity). It seems to me https plays an important role in ensuring we get correct checksums from the trusted site. > This bugzilla specifically mentions artifacts while I think the issue of > security is broader than just the artifacts... I agree and as mentioned above, metadata is probably more important than artifacts, it's probably a wider issue of whether we should fetch any http content by default in p2. > Also with signing, you can't really tamper signatures can you? One can tamper signatures, but they would then become invalid and the various checks in place would refuse to install the artifact with a wrong signature. However, it's possible to change to another signature, and this signature would be from another signer, that could try to use a "facade" that makes it seem official (eg writing ECLIРSE -with a cyrillic Р character instead of latin P), but this concern is not specific to p2 or HTTPS.
(In reply to Mickael Istria from comment #4) > > I'm thinking about p2 repos in general, not about download.eclipse.org in > particular. [...] > [...] but if we are concerned about network > tampering then I think it's fair to make HTTP disbled by default as > suggested by reporter. I'm a little bit confused about the motivation and the goal of this bug. Is it all about the particular services at eclipse.org and perhaps related mirrors? In that case you could perhaps say "we are concerned (or not)". But if you speak about p2 as a deployable technology and perhaps other non-Eclipse.org deployments, how can we be concerned about something (such as https access) not being disabled or not being the default configuration? Wouldn't that all be the responsibility of the deployer? Or am I completely misunderstanding the suggestion of the reporter?
(In reply to Eike Stepper from comment #5) > Is it all about the particular services at eclipse.org and perhaps related > mirrors? In that case you could perhaps say "we are concerned (or not)". No, the scope of this bug is p2 in general; and should we let p2 use HTTP by default if it's know to be vulnerable to man-in-the-middle attacks. > But if you speak about p2 as a deployable technology and perhaps other > non-Eclipse.org deployments, how can we be concerned about something (such > as https access) not being disabled or not being the default configuration? > Wouldn't that all be the responsibility of the deployer? I think it's easy to always say "that's the responsibility of the deployer", but in reality the underlying technology that does the installation (eg p2 or Maven) has a huge influence on how people will deploy. If we start having p2 disabling HTTP by default, then we send a clear sign to all providers that they should move to HTTPs and thus p2 becomes a lever of increased security instead of just dropping the ball to someplace else. See this interesting change from Maven: https://maven.apache.org/docs/3.8.1/release-notes.html#cve-2021-26291 . This is what triggered the discussion here; p2 should probably have a similar CVE filed.
(In reply to Mickael Istria from comment #6) > If we start having p2 disabling HTTP by default, then we send a clear sign > to all providers that they should move to HTTPs and thus p2 becomes a lever > of increased security instead of just dropping the ball to someplace else. So what about all folks that happily use p2 in http environments where such attacks aren't possible through other means, for example private and corporate networks? Would your clear sign make their services stop working?
(In reply to Eike Stepper from comment #7) > So what about all folks that happily use p2 in http environments where such > attacks aren't possible through other means, for example private and > corporate networks? Would your clear sign make their services stop working? Good question. As far as I know, there wasn't too much negative feedback about Maven, which isn't too different. So I'm under the impression that although this can be an issue for some cases, requiring those cases to adapt might be less an issue than letting man-in-the-middle attack widely possible.
> Also, artifacts have checksums that would prevent successfully tampering the files themselves. To me it looks like at least for mirrors this metadata could be used to verify the integrity of downloads, that includes: - Not downloading anything else (without checksums) from the mirror - Requiring that every artifact listed in the original repository has checksum and file size information - Not trusting insecure hash algorithms (?) I am not very familiar with p2 (as well as Tycho), so it could be that they already behave this way. Maybe trusting mirrors is also a different topic (and should be discussed in a separate issue?), but it was also one of the concerns I voiced on the GitHub issue. >> So what about all folks that happily use p2 in http environments where such >> attacks aren't possible through other means, for example private and >> corporate networks? Would your clear sign make their services stop working? > > Good question. As far as I know, there wasn't too much negative feedback about > Maven, which isn't too different. I am afraid the situation for Maven is a different one. For Maven you have Maven Central containing the majority of the artifacts. Additionally in the past the big Maven repositories have dropped unencrypted HTTP support (thanks to the effort of multiple security researchers), see https://blog.sonatype.com/central-repository-moving-to-https. So most users of Maven had already switched to HTTPS before Maven now dropped support for it. Additionally the other aspect of the Maven vulnerability was that Maven uses repositories declared by dependencies. However, due to Maven's Repository Order logic (https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order) in most (if not all cases) it would not have used the repositories declared by dependencies, because it already found the artifacts in Maven Central. Another aspect for Maven is also that there is no "auto-updater", so it is very likely that a lot of users are still using versions below 3.8.1. It might therefore be difficult to tell how many are actually affected by unencrypted HTTP being blocked by default. For Tycho the situation is a different one: - A large majority of code examples I saw (and even the ones inside the Tycho repository) are using unencrypted HTTP URLs, at least for the Eclipse p2 repositories. - There is (from my understanding) no one big p2 repository like Maven Central, so most users of Tycho have declared a custom repository (and as above, the URL most likely uses HTTP). - p2's support of mirrors (and maybe other features as well) define URLs inside the repository metadata. And even for the latest Eclipse repository some URLs (e.g. `p2.mirrorsURL`) still use HTTP. - The Eclipse repositories (such as http://download.eclipse.org/releases/2021-06/) don't upgrade HTTP to HTTPS when accessed from the browser. So when a user copies the URL (or edits an older download URL) they will keep using unencrypted HTTP unless they manually change it as well. These were the reasons why I originally proposed (for Tycho) in the GitHub issue to automatically upgrade URLs to HTTPS (opt-out). This would at least address the main point of this issue which is the vulnerability against man-in-the-middle attacks. In the future it might then be a cleaner solution to block HTTP URLs instead (opt-out). Though as raised by Mickael Istria on the GitHub issue, upgrading to HTTPS might lead to unexpected (or cryptic) failures in case the repository does not properly support HTTPS. So the tooling would have to handle such errors (but only when they occurred for the automatic HTTP -> HTTPS upgrade) and wrap the exception in an exception with more useful message, explaining that an upgrade was attempted. What do you think?
(In reply to Some User from comment #9) > To me it looks like at least for mirrors this metadata could be used to > verify the integrity of downloads, that includes: > - Not downloading anything else (without checksums) from the mirror > - Requiring that every artifact listed in the original repository has > checksum and file size information > - Not trusting insecure hash algorithms (?) Those checksum & size metadata are not mandatory, but in practice, they're always here in artifacts.xml file that are defined in a p2 repo. So yes, they are used to verify that the content we get from the site or a mirror does match what's expected by the metadata. However, those metadata files can be accessed by HTTP so they're also the target of man-in-the-middle attack. In practice, someone who want to hack and installation would only need to replace the metadata files, from there, they can do basically whatever they want, like fetching from another URL or some other mirrors. So it seems like we can assume that as long as metadata are immune to attacks and contain checksums+size, the whole installation is almost immune to attacks. > Maybe trusting mirrors is also a different topic (and should be discussed in > a separate issue?), but it was also one of the concerns I voiced on the > GitHub issue. As discussed above, I think we can assume that in the mirrors can be trusted as the content we get from them is verified against checksum retrieved from the "master" site. > I am afraid the situation for Maven is a different one. For Maven you have > Maven Central containing the majority of the artifacts. Same for p2: 1 main p2 repository ( https://download.eclipse.org/releases/latest/ ) and many other ones wherever else. > Additionally in the > past the big Maven repositories have dropped unencrypted HTTP support Same for download.eclipse.org, and many other download servers, which has disabled HTTP support some time ago. > Additionally the other aspect of the Maven vulnerability was that Maven > uses repositories declared by dependencies. However, due to Maven's > Repository Order logic > (https://maven.apache.org/guides/mini/guide-multiple-repositories. > html#repository-order) in most (if not all cases) it would not have used the > repositories declared by dependencies, because it already found the > artifacts in Maven Central. Headless p2 (used by eg. Tycho or CLI) doesn't inject extra repositories without user explicitly adding them. With the UI, there is a "Contact all software sites" checkbox, which is usually turned on in order to allow resolving dependencies over other repositories. IIRC, the Eclipse IDE comes with 2 repositories enabled by default: latest EPP and latest Platform. > For Tycho the situation is a different one: Tycho-specific issues are to be discussed on Tycho issue tracker. Let's keep them aside of this discussion which is focused on p2. > - p2's support of mirrors (and maybe other features as well) define URLs > inside the repository metadata. And even for the latest Eclipse repository > some URLs (e.g. `p2.mirrorsURL`) still use HTTP. As discussed above, if we have checksums in the metadata and metadata are fetched with HTTPS, then it should be impossible to get an incorrect/corrupted/tampered artifact. All of people who have used Eclipse IDE & p2 for a long time were actually hit at least once by an installation process that was failing because of some mirror serving wrong (out of date) content and artifact wasn't matching expected checksum. > - The Eclipse repositories (such as > http://download.eclipse.org/releases/2021-06/) don't upgrade HTTP to HTTPS > when accessed from the browser. So when a user copies the URL (or edits an > older download URL) they will keep using unencrypted HTTP unless they > manually change it as well. Can you please report it to the infra team for consideration? That would be at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Servers
What about going the slow path here? I'm afraid that disabling http/upgrading to https will break way too much at once. So what about: * add heavy warning about http usage for 2021-12 release * disable http for 2022-03 with ability for users to enable it explicitly via some command line parameter (no UI for that as it's too much effort and will make users push for the change respective providers) * remove the command line option for 2022-06 or 09
Even slower, I think we could just do nothing in p2 in the end, and just focus on the infra forcing redirection from http to https. We don't need to disable http fully, only the metadata needs to be protected (assuming they contain checksums). > * add heavy warning about http usage for 2021-12 release +1, it would be nice to show such warning in the UI, with a worrying symbol like web browser are doing in the wizard when user enters an URI with http protocol; and with some log when http is used in order to fetch metadata.
> Those checksum & size metadata are not mandatory, but in practice, they're > always here in artifacts.xml file that are defined in a p2 repo. But that would require changes nonetheless to fail if an artifact is downloaded over HTTP or from a mirror, and no checksum information is available. If I see that correctly, the current behavior is to simply download the artifact without any checks. >> Additionally in the past the big Maven repositories have dropped unencrypted >> HTTP support > Same for download.eclipse.org, and many other download servers, which has > disabled HTTP support some time ago. Has it really "disabled" HTTP support? At least from the browser I seem to be able to download http://download.eclipse.org/releases/latest/compositeArtifacts.jar (note the 'http:') just fine without any issues. Maven has really _dropped_ HTTP support. When I try to access http://repo1.maven.org I get an HTTP 501, and therefore builds tools would fail. > Headless p2 (used by eg. Tycho or CLI) doesn't inject extra repositories without user explicitly adding them. My point here was rather that, despite Maven offering the possibility for dependencies to declare custom repositories, in reality they would rarely or never be used by Maven for the dependency lookup. Whereas for p2 there seem to be multiple places within the metadata where URLs can specified. For the `mirrorsURL` it would indeed not be a problem (assuming that checksums are verified). But another example I noticed is https://download.eclipse.org/releases/oxygen/compositeArtifacts.jar which specifies an unecrypted HTTP URL. So for p2 there might be more places to look out for, and more situations where in reality URLs in the metadata are actually used, and can therefore not be changed manually to use HTTPS by the user of p2 / Tycho. > Even slower, I think we could just do nothing in p2 in the end, and just focus on the infra forcing redirection from http to https. Is "infra" here referring to p2 components or the download.eclipse.org site? In case of the latter, then this would not really be effective: 1. Users might be using other repositories where unencrypted HTTP access is still supported 2. Having the server upgrade / redirect from HTTP to HTTPS adds no security. Unless the client enforces this upgrade, an attacker could easily make the client continue using HTTP or respond with an HTTP redirect to their own malicious repository using HTTPS. > Can you please report it to the infra team for consideration? That would be at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Servers Have created https://bugs.eclipse.org/bugs/show_bug.cgi?id=575731 for that. I have also found https://bugs.eclipse.org/bugs/show_bug.cgi?id=444350 which overlaps in parts with the discussion we are having here.
(In reply to Mickael Istria from comment #12) > I think we could just do nothing in p2 in the end, and just > focus on the infra forcing redirection from http to https. I agree and I appreciate your effort to make Eclipse.org an even safer place. Should this bugzilla moved out of p2's inbox then? What about Eclipse Foundation|Community|Infrastructure?
(In reply to Mickael Istria from comment #12) > I think we could just do nothing in p2 in the end, and just > focus on the infra forcing redirection from http to https. I've kind of changed my mind here (again) as I believe it's also important to drive towards more security. However, I don't think we need to enforce HTTPS for artifacts: as the discussion reveals if metadata are free from man-in-the-middle attacks (thanks to HTTPS) and artifacts have good checksums/size info, then it's fine to download with HTTP and compare the received file with what is in metadata and reject it if it doesn't match. @Eike: are you aware of concrete setups that would be broken by such a change? Are those worth avoiding a global security gain if they are given one option to allow http?
(In reply to Mickael Istria from comment #15) > @Eike: are you aware of concrete setups that would be broken by such a > change? Are those worth avoiding a global security gain if they are given > one option to allow http? I'm not sure what change you're proposing now. For all I know p2 is behaving already such that tampered artifacts can not be installed if the metadata can not be hacked. Whether metadata can be hacked (via http) or not (via https) is a decision of the metadata provider. If you want to give the end user more choice you can add a new option in p2 to disallow the use of metadata over http. But if you make that new option the new default you'll probably break someone. Is that your new proposal?
(In reply to Eike Stepper from comment #16) > Whether metadata can be hacked (via http) or not (via > https) is a decision of the metadata provider. Yes, but since metadata do provide the essential part of ensuring we get the right artifacts (ie checksums), this is the critical point to protect against man-in-the-middle attacks. If metadata are safe (not hacked) and do contain checksums to verify artifact, then the overall installation is fine and that the retrieved artifacts do match expectation of the metadata provider. My proposal would be that we move -progressively- towards disabling fetching metadta via http to encourage the metadata provider to move to the safer https and to protect end-users of the Eclipse IDE or most Eclipse RCP applications against such man-in-the-middle attacks when installing artifacts. I'm not certain that as a technology that's about installing software, we should really consider that we need to consider the metadata provider decision to be hackable as a 1st class citizen; compared to p2's decision of preventing its millions of users against man-in-the-middle attacks. > If you want to give the end > user more choice you can add a new option in p2 to disallow the use of > metadata over http. Yes, that would be 1 increment; this + a warning when using http. > But if you make that new option the new default you'll > probably break someone. We're somehow already kind of breaking millions of users by making their p2 installations vulnarable to man-in-the-middle attacks. IMO, the balance is on the side of more security rather than on the side of backward compatibility. And even about backward compatibility, this was my previous question, are you concretely aware about 1 case where moving away from http to https would be a major issue? Do you happen to personally support one of them? Ie is your reluctance based on a current need you have, or more on a dogmatic (not to be read negatively) backward compatibility concern? As far as I see, most p2 repos that get provided in open-source (be it with download.eclipse.org, or bintray, or GitHub sites, or major Nexus instances...) are using https by default as the underlying server simply abandoned http; and it's been so for some time now; so I don't foresee such a restriction towards https for p2 metadata as a big concern, especially if we plan for it over 6 months and communicate about it early enough.
I really like the direction in which this discussion is moving now; but as mentioned by comment#13 there is metadata out there which uses HTTP URLs, such as composite repository metadata created for older Eclipse releases. Disabling unencrypted HTTP would prevent users from using these repositories at all, forcing them to allow all unencrypted HTTP usage. As mentioned before I would therefore suggest the following setting with the following values: insecureHttpConnections: - block Completely blocks all unencrypted HTTP connections (potential exception might be mirrors, assuming that mirror usage always enforces checksums; currently not the case). - use-https / upgrade-to-https Always uses HTTPS for connections, even if URLs use HTTP. However, a warning should be logged in these cases, explaining that an HTTP URL was encountered and the connection will be upgraded. Connection errors need to be handled properly to indicate to the user that an HTTPS upgrade was attempted, but failed. - allow Same as the current behavior; vulnerable to man-in-the-middle attacks. For connections using unencrypted HTTP a warning should be logged. Additionally it would be good to log a warning at the start just for that fact that "allow" was chosen (even if no HTTP URLs are encountered). Initially the default should become "use-https", as pointed out by Mickael Istria the major repositories do support HTTPS so this would not be a breaking change, even for old metadata using HTTP URLs. The next step in the future could be then to make "block" block; this will definitely guarantee then that maintainers become aware and ideally use HTTP URLs, protecting those who are using older or different libraries no enforcing usage of HTTPS yet. Users can still switch manually back to "use-https" if necessary. Eventually you will probably need to talk about CVEs again, when a solution has been implemented. If Maven got one for nearly the same situation, p2 and dependent projects will need CVEs too. If done properly code scanning tools such as GitHub's Dependabot can then notice the vulnerable dependencies and help making sure that developers upgrade their dependencies or build tools (such as Tycho).
> to make "block" block Sorry, meant > to make "block" the default
(In reply to Some User from comment #18) > Disabling unencrypted HTTP would prevent users from using these repositories > at all, forcing them to allow all unencrypted HTTP usage. I don't see it as an issue. The case of some people needing to enable HTTP because of some repos using HTTP is more an issue that has to become the responsibility of the user (enabling http) and/or of the provider p2 repo (enabling https). I don't think p2 has to try to be smart here, since the final goal is to make most p2 repo provider stop using http at all. > As mentioned > before I would therefore suggest the following setting with the following > values: > insecureHttpConnections: > - block [...] > - use-https / upgrade-to-https [...] > - allow [...] IMO, only block and allow are enough. > Eventually you will probably need to talk about CVEs again, when a solution > has been implemented. If Maven got one for nearly the same situation, p2 and > dependent projects will need CVEs too. If done properly code scanning tools > such as GitHub's Dependabot can then notice the vulnerable dependencies and > help making sure that developers upgrade their dependencies or build tools > (such as Tycho). Right, that makes sense.
I opened https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/97 to start formalizing the CVE report. Note that I'm not experienced at all with CVEs, so I basically won't ba able to take care of it without guidance and assistance. In the best case, this becomes a CVE and the CVE is interpreted as severe enough to allow direct action such as disabling HTTP fully by default in p2; and just have some option (eg a system property) to re-enable it.
I think the title doesn't really reflect the problem... I think the proposal is to focus on secure access to the metadata which is completely different from what the title suggests. > (In reply to Mickael Istria from comment #20) > (In reply to Some User from comment #18) > > Disabling unencrypted HTTP would prevent users from using these repositories > > at all, forcing them to allow all unencrypted HTTP usage. > > I don't see it as an issue. The case of some people needing to enable HTTP > because of some repos using HTTP is more an issue that has to become the > responsibility of the user (enabling http) and/or of the provider p2 repo > (enabling https). I don't think p2 has to try to be smart here, since the > final goal is to make most p2 repo provider stop using http at all. > I'm concerned that a large number of marketplace listings will be broken and even repositories at Eclipse will be broken. I can gather data to back that concern up with facts after I'm back from traveling... The problem as I see it is that the user is not in a good position to fix composite sites or site references. They must rely on someone else to fix them and those who need to fix the sites may well be quite unresponsive leaving the user with a bad impression of Eclipse. Yes we can tell them it's for their safety and comfort but it seems me could make it more comfortable without making it less safe. I.e., why not just upgrade to https automatically so that things just continue to work except when the site host itself does no support https? That seems less likely to cause problems than simply blocking access and then requiring the site itself to be fixed... > > As mentioned > > before I would therefore suggest the following setting with the following > > values: > > insecureHttpConnections: > > - block [...] > > - use-https / upgrade-to-https [...] > > - allow [...] > > IMO, only block and allow are enough. > If you can only provide two options for whatever reason, redirect or allow seems also sufficient to address the problem.
I've assigned CVE-2021-41033 and have reported this as vulnerability against Eclipse Equinox.
Created attachment 287207 [details] A list fo repositories and their non-https absolute child URIs These are the +1400 cases where a download.eclipse.org repository has an absolute child URI that is not https.
BTW, I've included these as errors in the report: https://download.eclipse.org/oomph/archive/p2-index/
I think the CVE registration is possible generating a lot of false positives for developers using tools like owasp. Especially because of the high rating. As I understand the solution is not yet released, which makes upgrading to a safe version impossible. We use the FileLocator from org.eclipse.equinox.common, which is at this moment version 3.15.0 on mvn central. However the CVE states that the bug can be found in every "eclipse.equinox" bundle up to version 4.21 a) is org.eclipse.equinox.common correctly marked as vulnerable by this CVE or is it about other parts of the equinox bundle? b) if org.eclipse.equinox.common is vulnerable, is it possible to make the CVE more precise with specific different versions? As it is right now org.eclipse.equinox.common will need a version of 4.22 to not be marked as vulnerable which is probably not the expected next version.
> a) is org.eclipse.equinox.common correctly marked as vulnerable by this CVE > or is it about other parts of the equinox bundle? Our practice has been to set the "product name" in CVEs to the project. In this case, I set the product name to "Eclipse Equinox". The short version is that I don't know how the data that we provide to Mitre through the CVE programme is converted into the information that tools like owasp use, so I'm not sure what we need to do differently. It's time to sort that out. Pointers welcome.
(In reply to Chris Notenboom from comment #26) > I think the CVE registration is possible generating a lot of false positives > for developers using tools like owasp. Especially because of the high rating. > > As I understand the solution is not yet released, which makes upgrading to a > safe version impossible. > > We use the FileLocator from org.eclipse.equinox.common, which is at this > moment version 3.15.0 on mvn central. However the CVE states that the bug > can be found in every "eclipse.equinox" bundle up to version 4.21 > > a) is org.eclipse.equinox.common correctly marked as vulnerable by this CVE > or is it about other parts of the equinox bundle? > b) if org.eclipse.equinox.common is vulnerable, is it possible to make the > CVE more precise with specific different versions? As it is right now > org.eclipse.equinox.common will need a version of 4.22 to not be marked as > vulnerable which is probably not the expected next version. The version 3.15 of org.eclipse.equinox.common is a bundle version while version 4.21 must be referring to the Eclipse Equinox project release version. With that said, the statement in the CVE is a distraction: "In all released versions of Eclipse Equinox, at least until version 4.21 (September 2021)..." Here we are only talking about the p2 bundles that deal communicating with remote p2 repositories. This has nothing to do with all the other bundles included in Equinox. The org.eclipse.equinox.common is not affected by this Equinox p2 issue.
I see that now http://download.eclipse.org redirects to https Should p2 respect HSTS ? Then a http request will only be done once for the site. Should a 'HTTP/1.1 301 Moved Permanently' update the 'Available Software Sites' list? By using trace from https://wiki.eclipse.org/Equinox/p2/Reporting_Problems I see that if there is a repo such as http://download.eclipse.org/mat/latest/update-site/ then it does a 2023/01/04 16:17:03:468 GMT [DEBUG] MainClientExec - Executing request GET /mat/latest/update-site/p2.index HTTP/1.1 2023/01/04 16:17:03:469 GMT [DEBUG] MainClientExec - Target auth state: UNCHALLENGED 2023/01/04 16:17:03:470 GMT [DEBUG] MainClientExec - Proxy auth state: UNCHALLENGED 2023/01/04 16:17:03:470 GMT [DEBUG] headers - http-outgoing-5 >> GET /mat/latest/update-site/p2.index HTTP/1.1 2023/01/04 16:17:03:471 GMT [DEBUG] headers - http-outgoing-5 >> Cache-Control: max-age=0 2023/01/04 16:17:03:471 GMT [DEBUG] headers - http-outgoing-5 >> User-Agent: p2/1.3.200.v20210613-1953 (Java 17.0.4.1+1 IBM Corporation; win32 10.0.0 x86-64; en_GB) org.eclipse.mat.ui.rcp.MemoryAnalyzer/unknownBuildId (org.eclipse.mat.ui.rcp.application) 2023/01/04 16:17:03:471 GMT [DEBUG] headers - http-outgoing-5 >> Host: download.eclipse.org 2023/01/04 16:17:03:472 GMT [DEBUG] headers - http-outgoing-5 >> Connection: Keep-Alive 2023/01/04 16:17:03:472 GMT [DEBUG] headers - http-outgoing-5 >> Accept-Encoding: gzip,deflate which then gets a redirect to https 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << HTTP/1.1 301 Moved Permanently 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << Server: nginx 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << Date: Wed, 04 Jan 2023 16:17:00 GMT 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << Content-Type: text/html 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << Content-Length: 162 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << Connection: keep-alive 2023/01/04 16:17:03:586 GMT [DEBUG] headers - http-outgoing-5 << Location: https://download.eclipse.org/mat/latest/update-site/p2.index 2023/01/04 16:17:03:586 GMT [DEBUG] MainClientExec - Connection can be kept alive indefinitely 2023/01/04 16:17:03:586 GMT [DEBUG] DefaultRedirectStrategy - Redirect requested to location 'https://download.eclipse.org/mat/latest/update-site/p2.index' 2023/01/04 16:17:03:586 GMT [DEBUG] RedirectExec - Resetting target auth state 2023/01/04 16:17:03:586 GMT [DEBUG] RedirectExec - Redirecting to 'https://download.eclipse.org/mat/latest/update-site/p2.index' via {s}->https://download.eclipse.org:443 2023/01/04 16:17:03:586 GMT [DEBUG] PoolingHttpClientConnectionManager - Connection [id: 5][route: {}->http://download.eclipse.org:80] can be kept alive indefinitely and then the https response includes: 2023/01/04 16:17:04:040 GMT [DEBUG] headers - http-outgoing-7 << Strict-Transport-Security: max-age=63072000; includeSubDomains; preload p2 has already received a 'Strict-Transport-Security' reponse for another connection to download.eclipse.org but hasn't started the connection as https. Also later in the same run I tried another site and got a similar request repsonse: 2023/01/04 16:43:55:942 GMT [DEBUG] headers - http-outgoing-11 >> GET /mat/snapshots/update-site/content.xml.xz HTTP/1.1 2023/01/04 16:43:55:942 GMT [DEBUG] headers - http-outgoing-11 >> Cache-Control: max-age=0 2023/01/04 16:43:55:942 GMT [DEBUG] headers - http-outgoing-11 >> User-Agent: p2/1.3.200.v20210613-1953 (Java 17.0.4.1+1 IBM Corporation; win32 10.0.0 x86-64; en_GB) org.eclipse.mat.ui.rcp.MemoryAnalyzer/unknownBuildId (org.eclipse.mat.ui.rcp.application) 2023/01/04 16:43:55:942 GMT [DEBUG] headers - http-outgoing-11 >> Host: download.eclipse.org 2023/01/04 16:43:55:942 GMT [DEBUG] headers - http-outgoing-11 >> Connection: Keep-Alive 2023/01/04 16:43:55:942 GMT [DEBUG] headers - http-outgoing-11 >> Accept-Encoding: gzip,deflate 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << HTTP/1.1 301 Moved Permanently 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << Server: nginx 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << Date: Wed, 04 Jan 2023 16:43:53 GMT 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << Content-Type: text/html 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << Content-Length: 162 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << Connection: keep-alive 2023/01/04 16:43:56:051 GMT [DEBUG] headers - http-outgoing-11 << Location: https://download.eclipse.org/mat/snapshots/update-site/content.xml.xz
Project moved to https://github.com/eclipse-equinox/p2/ . If you want to have further discusion on the topic please propose it there
Fixed by https://github.com/eclipse-equinox/p2/issues/230
Hi Team , We see the below CVE's in the latest version 1.15.0 CVE-2023-44487 CVE-2021-42340 CVE-2022-29885 CVE-2022-42252 CVE-2022-45143 CVE-2023-46589 CVE-2022-23181 CVE-2015-4035 Can u check and confirm if any of them are false positives so we can suppress them?
Sorry, no one can research your list of CVEs on your behalf.
