Eclipse EDC: Anyone can add any verifiable credential to the Identity Hub, jeopardizing the availability and integrity of the entire connector

Basic information

Project name: Eclipse EDC

Project id: technology.edc

What are the affected versions?

I observed the vulnerability in version 0.3.1.

Maybe older or newer versions are affected as well.

Details of the issue

When running the MinimumViableDataspace example (mvd-legacy tag version) (which is using EDC version 0.3.1), I discovered an issue / vulnerability related to IdentityHub and the authentication among the connectors.

Permalink: https://github.com/eclipse-edc/MinimumViableDataspace/tree/067232f6416872548658f7ed6106694a412babff

The Connector used in MVD includes (among others) the following dependencies:

• org.eclipse.edc:identity-did-service
• org.eclipse.edc:identity-hub-credentials-verifier

Connectors authenticate to each other using (self-issued) JWTs that are signed by the sender's private key. The JWT is checked by the receiver by looking up the public key from the sender's DID-document (here via did:web, the sender's DID is noted as subject/issuer in the JWT) and verifying the signature (i.e., check whether the sender is really in possession of the private key associated with that DID). Then, the receiver fetches verifiable credentials (VC) from the sender's IdentityHub to retrieve the claims. The verifiable credentials returned by the sender's IdentityHub are verified by the receiver. One of the checks is that the subject of a verifiable credential must match with the connector's DID. If there is (at least) one verifiable credential with a subject unequal to the connector's DID stored in the IdentityHub, the verification and thereby the authentication fails completely (instead of just leaving out that unrelated VC/claims).

The Identity Hub (at least in this version) does not have any authentication or authorization in place to check who is allowed to add VCs and there is also no check that only VCs with a suitable subject (matching the connector's DID) are added.

So anyone who can access the Identity Hub API can push any Verifiable Credential to the IdentityHub.

The Identity Hub API is publicly accessible and its address is listed in the publicly accessible DID document. The Dataspace Authority (i.e., the "registration service") will push a membership credential as part of the onboarding process and other connectors reach out to the Identity Hub of other connectors to fetch the VCs.

This results in an easy to exploit vulnerability that threatens availability and integrity.

Anyone can push a VC with a different subject (that does not match with the connector's DID) to a connector's Identity Hub. As a result, that connector is no longer able to authenticate to other connectors because the authentication will always fail, because the Identity Hub's response includes that VC (with a subject that does not match with the connector's DID) that causes the whole verification to fail.

The Connector can no longer lookup other Connectors' catalogs. Negotiations are no longer possible. One cannot initiate new data transfers.

The connector is no longer able to interact with other connectors.

There is no endpoint to remove VCs from the Identity Hub. The only way to recover from this attack is to manually remove the malicious VC from the database of the IdentityHub (in case one uses the Identity Hub with persistence). In case of in-memory IdentityHub, one needs to restart the IdentityHub (but then all VCs will be lost). Onboarding (to receive the membership credential again) cannot be triggered again as the connector is still listed as already onboarded.

Nevertheless, an attacker could add a malicious VC again without much effort.

I would grade this vulnerability as a

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:H

9.0 / Critical

• AV Network, because the (unprotected) Identity Hub endpoint is exposed to the internet.
• AC Low, because creating a VC with different subject is easy, the request to add a VC to Identity Hub is easy and the address of a connector's IdentityHub is easy to retrieve. The POC payload provided in this report can be used as is. To attack another IdentityHub, attackers only need to send the request (as is) to another Identity Hub instance. The address can be found in the connector's public DID document.
• AT Present, as a vulnerable connector needs to use / include "org.eclipse.edc:identity-did-service" for IAM and " org.eclipse.edc:identity-hub-credentials-verifier".
• PR none, because the (unprotected) Identity Hub endpoint is exposed to the internet.
• UI none, no additional user interaction required
• VC none, as no information is leaked
• VI high, as the content of the Identity Hub is modified by an unauthorized party (lack of auth) resulting in serious consequences for the system.
• VA high, as the connector can no longer authenticate to other connectors / systems in the data space. The connector and the assets might be part of business critical processes. A company (and customers) might depend on the availability of this system.
• SC none, as no information is leaked
• SI none, as no information is modified in subsequent systems.
• SA high, the connectors and the assets might be part of business critical processes. Subsequent systems might depend on the availability of the vulnerable system.

The major issues are:

In IdentityHub:

• Missing authentication and authorization when pushing new VCs to the identity hub.
• Missing check in Identity Hub that only VCs with a suitable subject are allowed to be pushed/stored.

In Connector:

• Unfortunate handling of VCs with non-matching subject during verification of the VCs / fetching the claims (maybe they should be sorted out / ignored instead of failing the whole authentication)

Related Code parts

Why does the authentication among the connectors fail if the sender has a VC with non-matching subject in its Identity Hub?

• There is a check for exact match of the VC subject with the DID and if verification of only one VC fails, the whole verification of the JWT bearer token fails.
  • DecentralizedIdentityService.java#L101-L106
  • IdentityHubCredentialsVerifier.java#L71-L99
  • IdentityHubCredentialsVerifier.java#L103-L119
  • IdentityHubCredentialsVerifier.java#L129
  • JwtCredentialEnvelopeVerifier.java#L44-L47
  • JwtEnvelopeVerifier.java#L34
  • DidJwtCredentialsVerifier.java#L75-L92
  • IdentityHubCredentialsVerifier.java#L119
  • AggregatedResult.java#L35
  • IdentityHubCredentialsVerifier.java#L94

Why does the Identity Hub accept "CollectionsWrite" operation requests from unauthenticated requesters?

• There is no AuthN/AuthZ implemented for that.

Why does the Identity Hub accept VCs with subjects different from the Connector's DID?

• There is no check implemented for that.
• Maybe Identity Hub should support being used / shared for multiple connector instances... But then: Why is there no option to query the Identity Hub for VCs with a specific subject only?

Steps to reproduce

• Checkout and setup MVD using "mvd-legacy" tag version.
  • ./gradlew build -x test
  • ./gradlew -DuseFsVault="true" :launchers:connector:shadowJar
  • ./gradlew -DuseFsVault="true" :launchers:registrationservice:shadowJar
  • export MVD_UI_PATH=<provide proper value>
  • You might want to adjust the EDC_CATALOG_CACHE_EXECUTION_PERIOD_SECONDS settings in system-tests/docker-compose.yml to a value of 60 or so to have the logs not spammed that much
  • docker compose --profile ui -f system-tests/docker-compose.yml up --build to start MVD
• Check the catalog browser of company1 connector instance in the dashboard (http://localhost:7080), notice the assets displayed (one can see assets in the catalog browser of the Data Dashboard). Maybe wait 60s for another crawler run to see more.
• Push a VC with different subject to company1 connector's Identity Hub (see example request below, to insert such a malicious VC to the Identity Hub of company1 connector)
• That connector can no longer authenticate to other connectors. Wait for the next crawler runs. See errors in logs. Catalog Browser of attacked connector is eventually empty after some crawler runs (the connector can no longer retrieve the catalogs of other connectors).

Request to push a VC with non-matching subject to Identity Hub

POST request to http://localhost:7171/api/identity/identity-hub

Payload/Body (application/json):

{
  "messages": [
    {
      "data": "ZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SjJZeUk2ZXlKQVkyOXVkR1Y0ZENJNld5Sm9kSFJ3Y3pvdkwzZDNkeTUzTXk1dmNtY3ZNakF4T0M5amNtVmtaVzUwYVdGc2N5OTJNU0lzSW1oMGRIQnpPaTh2ZHpOcFpDNXZjbWN2YzJWamRYSnBkSGt2YzNWcGRHVnpMMnAzY3kweU1ESXdMM1l4SWl3aWFIUjBjSE02THk5eVpXZHBjM1J5ZVM1c1lXSXVaMkZwWVMxNExtVjFMMlJsZG1Wc2IzQnRaVzUwTDJGd2FTOTBjblZ6ZEdWa0xYTm9ZWEJsTFhKbFoybHpkSEo1TDNZeEwzTm9ZWEJsY3k5cWMyOXViR1F2ZEhKMWMzUm1jbUZ0WlhkdmNtc2pJbDBzSW5SNWNHVWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aVhTd2lhV1FpT2lKb2RIUndjem92TDJOdmJYQnNhV0Z1WTJVdWJHRmlMbWRoYVdFdGVDNWxkUzkyTVMxemRHRm5hVzVuTDJOeVpXUmxiblJwWVd3dGIyWm1aWEp6THpRNVlXVTBZV1JrTFdKbU1EZ3ROREE0TXkxaE9HSmxMV0U1TURZM1ltRTJOMk13TnlJc0ltbHpjM1ZsY2lJNkltUnBaRHAzWldJNlkyOXRjR3hwWVc1alpTNXNZV0l1WjJGcFlTMTRMbVYxT25ZeExYTjBZV2RwYm1jaUxDSnBjM04xWVc1alpVUmhkR1VpT2lJeU1ESTBMVEEzTFRJMlZEQTVPakV3T2pVM0xqQTVNRm9pTENKbGVIQnBjbUYwYVc5dVJHRjBaU0k2SWpJd01qUXRNVEF0TWpSVU1EazZNVEE2TlRjdU1Ea3dXaUlzSW1OeVpXUmxiblJwWVd4VGRXSnFaV04wSWpwN0luUjVjR1VpT2lKbmVEcGpiMjF3YkdsaGJtTmxJaXdpYVdRaU9pSm9kSFJ3Y3pvdkwySmhhMlYxY0M1cGJ5OW5ZV2xoTFhndGJISnVMbXB6YjI0aUxDSm5lRHBwYm5SbFozSnBkSGtpT2lKemFHRXlOVFl0WVRrMk0yTXlPREkyWTJFd1kyVTVNamhtTm1ZMFlqSTRZakZtWVRKbU16QTVNR0U0T0dWbVpXSXhaRE5pWXpkbVpUVXhaR000TkRZM05HVXlPVFEzWkNJc0ltZDRPbWx1ZEdWbmNtbDBlVTV2Y20xaGJHbDZZWFJwYjI0aU9pSlNSa000TnpnMU9rcERVeUlzSW1kNE9uWmxjbk5wYjI0aU9pSXlNaTR4TUNJc0ltZDRPblI1Y0dVaU9pSm5lRHBzWldkaGJGSmxaMmx6ZEhKaGRHbHZiazUxYldKbGNpSjlmU3dpYVdGMElqb3hOekl4T1RnMU1EVTNMQ0psZUhBaU9qRTNNamszTmpFd05UY3NJbWx6Y3lJNkltUnBaRHAzWldJNlkyOXRjR3hwWVc1alpTNXNZV0l1WjJGcFlTMTRMbVYxT25ZeExYTjBZV2RwYm1jaUxDSnpkV0lpT2lKb2RIUndjem92TDJOdmJYQnNhV0Z1WTJVdWJHRmlMbWRoYVdFdGVDNWxkUzkyTVMxemRHRm5hVzVuTDJOeVpXUmxiblJwWVd3dGIyWm1aWEp6THpRNVlXVTBZV1JrTFdKbU1EZ3ROREE0TXkxaE9HSmxMV0U1TURZM1ltRTJOMk13TnlJc0ltRjFaQ0k2SW1oMGRIQnpPaTh2WTI5dGNHeHBZVzVqWlM1c1lXSXVaMkZwWVMxNExtVjFMM1l4TFhOMFlXZHBibWN2WTNKbFpHVnVkR2xoYkMxdlptWmxjbk12TkRsaFpUUmhaR1F0WW1Zd09DMDBNRGd6TFdFNFltVXRZVGt3TmpkaVlUWTNZekEzSW4wLmtqbGp5SlFzNlNxSV9vUnkxWjkwTUIwekdWSmtvSUdaQU4xR1RCdUNlcTAyX0dVNkJkRGJnamU5MGlpRkQwRlFOQUpabWpYUXZnQndTWGtuRUtZWHlBYlBKU2hjQzZrN2V1MVpGX1ZzbU5VeWdtUFBHOXUzaEtCdkRzcVFzdzhKam5DeVFFWXNsRk5XTENfcnpDZmJiRFpSR3JWQy1pRFpya0s5cmVQZ0hhRmtxV1FPMnNURU9lZDFfQTRCRGw1ZWxpUmpWMGxaNzRsaU1GcmtBd3FVS0ZEdk5KUE9QQkpvY1dQRWVHQkUxczZwb3pyN1ZUTHNsWW5DZzYyZ3JSWGdIZUZva0hkZWZXTlJDemdSRjJ6UTUxWWcwRkZtdVI1NFNaaGkzbUZ4NWZWMFI4ZmRvY3d0cGIwVDR0cENMZFlPdFRWVHkyZWhWT0ZwZmhkYWNMOEZNZw==",
      "descriptor": {
        "method": "CollectionsWrite",
        "dataFormat": "application/vc+jwt",
        "dateCreated": 1718880898,
        "recordId": "test1234"
      }
    }
  ]
}

Logs (excerpt)

company2 | DEBUG 2024-08-05T09:49:11.0300388 DSP: Unauthorized: Failed to get verifiable credentials: Failure verifying JWT token: JWT sub claim has value https://compliance.lab.gaia-x.eu/v1-staging/credential-offers/49ae4add-bf08-4083-a8be-a9067ba67c07, must be did:web:did-server:company1

company1 | Caused by: org.eclipse.edc.spi.EdcException: {"@type":"dspace:CatalogError","dspace:code":"401","dspace:reason":"Token validation failed.","@context":{"dct":"https://purl.org/dc/terms/","edc":"https://w3id.org/edc/v0.0.1/ns/","dcat":"https://www.w3.org/ns/dcat/","odrl":"http://www.w3.org/ns/odrl/2/","dspace":"https://w3id.org/dspace/v0.8/"}}

Do you know any mitigations of the issue?

One could use a Web Application Firewall (WAF) or so in front of the Identity Hub API that blocks "CollectionsWrite" operation requests to the IdentityHub API (i.e., prevent adding new VCs to the Identity Hub).

made the issue visible to everyone

assigned to @mspiekermann

made the issue confidential

@mspiekermann please take a look also at this report.

made the issue visible to everyone

assigned to @platzel

made the issue confidential

@platzel could you please take a look at this report and provide an assessment or suggest another project member? ty

First off, this assessment references code that was never intended for production use, only for demonstration purposes. Unfortunately, version 0.3.1 of either component is completely outdated and will not receive any further updates as it has since been completely overhauled.

To me, the vulnerability is thus inconsequential.

Fully agree to Paul's comment and also already aligned with other committers. What would be the steps to take, if vulnerability is inconsequential? Do we still need to file an answer via a specific process?

@mspiekermann @platzel a code that is only for demonstration purposes does not receive CVEs. The fact of the code being supported or not is not a factor.

However, when I'm looking into the code, it doesn't look obvious that this code was not expected for production. I think it will be a good idea to mark it clearly in the documentation in the SECURITY.md and/or README of repositories.

To be clear, IdentityHub currently is not a demo project, but it was back then. The code that is referenced (0.3.1) is very old, ~ 10 months at the time of this writing. IdentityHub has since been completely rewritten to the point where the affected classes don't even exist anymore.

The MVD is by its very nature a test/demo/sample project, which is stated clearly in its documentation.

I don't think mentioning a vulnerability in an area of code that doesn't exist anymore is necessary, or even a good idea. We could state "please always use the latest version", but that should go without saying.

@platzel the possible confusion might come from the fact that someone looking into https://github.com/eclipse-edc/MinimumViableDataspace/tree/main will find only "mvd-legacy" as an existing release. This is then likely that they will grab it for their tests. Do you have an idea how to make it clear to users which version they should take?

As this code was for demo purposes, we can explain the situation to the original reporter. As said, there's no CVE for this one, in my opinion.

that's not a release, only a git tag, that we created to mark the move over to the "new" MVD. I think it's reasonable to expect even junior developers to recognize the difference.

MVD does not publish any artefacts (docker images, Maven modules, ...) so they can't "grab" anything.

I also think that it is the responsibility of a reporter to a) be familiar with the code base to a degree where they don't analyse vastly outdated code, and b) - failing that - to follow this discussion here

If this a sample application to demonstrate the use of the technology and flaws in it have been fixed in the mean time with no binary releases being made so far I would also tend to leave it as is. Maybe indicate in the readme that previous, legacy version of the sample contained a vulnerability and should not be used as such. Also noting that flaw / vulnerability might help as a reminder or reference you can point to if questions like that arise (a similar one had been raised a couple of weeks ago afair).

just my 2c.

yeah, can't be too cautious... although stating "please always use the latest version" feels a bit like "water is wet" TBH

This vulnerability report is not about the "MVD", it is about the "Identity Hub" and the modules/artifacts published from that repository (https://github.com/eclipse-edc/IdentityHub). "MVD" was just an example setup to demonstrate the issue / vulnerability that was present in an older version of the "Identity Hub" modules more easily.

I share your point of view that the vulnerability is not a big deal / inconsequential for the current or upcoming releases (as the Identity Hub was overhauled meanwhile). Nevertheless, the reported vulnerability is present in the version / release mentioned in this report. Thus, this vulnerability report is - from my point of view - valid and the affected versions should be marked as having this vulnerability. One cannot expect that developers always use the most recent versions and rush for new releases (without knowing about the presence of a vulnerability in their version). Dependency checkers should report that those old versions are vulnerable.

From my point of view, artifacts from the Identity Hub repository that were publicly released (version 0.3.1) have the reported vulnerability.

The MVD is an example how to set up / build connectors and form a data space. Surely, it is for demonstration purposes only.

But the components/modules that were used (Connector, Identity Hub, other modules/packages), they are public releases (artifacts @ maven central) and they were/are not clearly labeled as "not production ready" or "demo only". These modules are the building blocks / modules that EDC is offering to the community to create their own data spaces / data space components.

For a long time, MVD was stuck at EDC version 0.3.1 - Only recently, MVD has been updated to use newer versions of EDC (July 2024, one month ago).

Many people might have seen MVD and played around with it (and were thereby using the old EDC components). And as the MVD was outdated for such a long time, chance is high that some people still use those old versions as they used the concepts and EDC components used in MVD as their starting point but did not do any updates since then as there was no reason for them (yet) or too many things changed fundamentally making an upgrade quite hard for them.

One might not expect that all consumers of public releases (developers) update their dependencies regularly and rush for any new release (without good reasons). If they have a running setup without known vulnerabilities in the dependencies they use, it could be fine for them to stick to an older release version.

Imagine environments where companies check / audit and freeze versions of their dependencies to protect from supply chain attacks. Changing the dependency version would require them to re-audit them. => Maybe companies are reluctant to updating dependencies if there is no strong need (e.g., new feature they want to use or a vulnerability that has been fixed).

sovity GmbH for example is still using EDC version 0.2.1 for their connectors (https://github.com/sovity/edc-ce).

It is easy to say that the public release of that component was not meant to be production ready or just for demonstration purposes back then. And that developers need to make sure to always use the newest version of a dependency (as older ones might have vulnerabilities no one every talks or knows about for sure).

I think this is not how it works in many companies or how it should be. Teams might not be able to just simply update their EDC dependencies whenever there is a new release as even minor releases can introduce massive changes and can break interoperability. (btw. EDC did not have a single major release yet)

For https://github.com/eclipse-edc/IdentityHub/tree/v0.3.1 I think there was no clear statement that it is for demonstration purposes only. At least it was/is not obvious. And the MVD (as a demo example) showcased that component (in that version) for a long time as an EDC component that can be used to handle VCs in IAM DID setups.

Today's Identity Hub might work completely different (and is not affected by the vulnerability anymore) but the old version (public release 0.3.1) has the vulnerability reported above.

Isn't it valid to report a vulnerability that affects older versions of a product? Should any vulnerability report that does not target the most recent state of the code be considered "inconsequential"?

Just because something is old, it does not necessarily mean that no one is using it anymore.

In #234 (closed) @mrybczyn said "the issue has been already fixed as I can understand and it will be fixed in ... if I understand correctly. However, it has been there in a a publicly released version. ..." (#234 (comment 2617445)) - I think this is a similar case here. The issue was present in a publicly released version (0.3.1) and has been already fixed by overhauling the whole Identity Hub. Nevertheless, version 0.3.1 clearly has this vulnerability. And for users of the dependency, there was/is no big warning that one should not use it in production or that is has this vulnerability.

Here we have:

• Missing authentication and authorization when pushing new VCs to the identity hub.
• Missing check in Identity Hub that only VCs with a suitable subject are allowed to be pushed/stored.
• Unfortunate handling of VCs with non-matching subject during verification of the VCs / fetching the claims

Resulting in severe degradation of availability of the connector in the dataspace (in possible business-critical processes) + unauthorized changes (violation of integrity).

Wouldn't it be appropriate to have a CVE for that as well so developers can be made aware of these old version(s) having that vulnerability (dependency checkers should issue a warning for those old versions)? Without it, they might not notice that their old dependencies are affected by the issue and that they should really consider updating.

For me, the reported issue qualifies as "a vulnerability in the project code for an Eclipse open source project" similar to #234 (closed) . The only difference is, that the vulnerability is no longer present in the current release as the implementation was overhauled (but still, the old version from less than 1 year ago is affected and (as far as I know) no one has published something about the vulnerability existing in that old version yet).

Considering the high CVSS score, it might be better to be safe than sorry.

Therefore, I suggest assigning a CVE, publishing the report, etc. so that for example dependency checkers can warn developers that are still using those old releases/versions of the Identity Hub related modules.

But in the end it is up to you / the EDC team how to handle this report for the (old) versions of the Identity Hub modules.

If you do not want to assign a CVE or take any measures, please remove the confidentiality flag from this issue so we can share that insights (including your assessment of the report) with the public.

like I said, the version of IdentityHub that was based on DWN was never intended to be even close to production-ready (no documentation, no real testing, no hardening,...) and the fact that there are Maven artefacts does not change that.

I very much doubt that any company would blindly use a project such as this in their production code base.

sovity GmbH for example is still using EDC version 0.2.1 for their connectors (https://github.com/sovity/edc-ce).

That is of no relevance here. Downstream projects that (for whatever reason) refuse to keep up-to-date with current developments are on their own and we cannot cater to their needs. And as far as i know, Sovity does not use IdentityHub.

Dependency checkers should report that those old versions are vulnerable.

If dependency checkers are used (as they should be), they should also warn about a grossly outdated version, which is the much bigger issue here.

Without it, they might not notice that their old dependencies are affected by the issue and that they should really consider updating.

The urgent need to update does not only stem from that vulnerability, but from the fact that the code is completely obsolete now.

If you do not want to assign a CVE or take any measures, please remove the confidentiality flag from this issue so we can share that insights (including your assessment of the report) with the public.

I certainly cannot decide this on my own, this will have to be brought to the EDC Committer group. My personal opinion is that opening a CVE for an old version that has no relevance anymore and will receive no support anyways is a waste of time and resources because no-one should be using it.

If we know that old versions of EDC are used in the wild we certainly can not force companies to update to a more recent version if they refuse to do so or simply have other priorities. However, if we are aware of potential security vulnerabilities in such versions, it is responsible to disclose that information for such companies to see the absolute need to update.

If they still refuse to do so, they are indeed on their own, and following the CRA they will probably be held accountable for that in the future. However not disclosing such vulnerabilities would not be the right thing to do. You could even see that as an additional incentive for users to update to a more recent version as older versions are known to contain vulnerabilities.

The decision of the EDC Committers is as follows:

No CVE will be opened. Instead, we will put a note into IdentityHub's GitHub landing page with the following content:

Older versions of IdentityHub (in particular <= 0.3.1 ) must not be used anymore, as they were intended for proof-of-concept purposes only and may contain significant security vulnerabilities (for example no authn/authz on the API) and possibly others. Please always use the latest version of IdentityHub.

Maybe you can consider including a link to this report (i.e., https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/235) in the note so people can easily find more information about it and our discussion.

E.g.:

Older versions of IdentityHub (in particular <= 0.3.1 ) must not be used anymore, as they were intended for proof-of-concept purposes only and may contain significant security vulnerabilities (for example no authn/authz on the API) and possibly others. Please always use the latest version of IdentityHub.

Thanks, we will take that into consideration as well.

There might be no reason to keep this issue/report confidential any longer. Could you please consider removing the confidential flag or provide more details about the next steps / timeline?

The fact aside that I personally don't have permissions to remove the flag, I also don't see the value in - or reason for - this issue being made public.

so we worked on a sample SECURITY.md file for repositories that are about educational / demonstration code. Could you take a look at https://github.com/eclipse-csi/security-handbook/pull/10 and let us know if this would appropriate in this case?

We could then add this SECURITY.md file to the repo and adjust it as necessary and also point out in the README that old versions contain a vulnerability and link to that ticket.

Once the ticket is closed we will also make it non-confidential.

the repository in question is not for educational purposes, at least not anymore. the security warning that was put in the repo's landing page should make that clear.

LGTM, the SECURITY.md that I was referring to should serve as a template that you can use and adapt to your needs. I still think that is it useful to add something like that to a repo just so that people know exactly where to find that info.

We also want to make that as easy as possible to setup using otterdog, but that might still take a while.

ah, i noticed IdentityHub does not have a SECURITY.md at all. wasn't aware of that. that must be fixed, I agree. Could I use this template as basis?

Could you take a look at https://github.com/eclipse-csi/security-handbook/pull/10 and let us know if this would appropriate in this case?

@netomi The example-code-SECURITY.md states

This repository contains code for educational and / or demonstration purposes only and SHOULD NOT be used for production. In accordance with the latest CNA rules, no CVE IDs will be assigned for vulnerabilities reported to this repository

I'm wondering whether you are referring to this rule:

4.2.18 CNAs MUST NOT assign CVE IDs for Vulnerabilities that have been deliberately implemented for educational and research purposes, for example, in Products such as OWASP WebGoat.

With the statement "for Vulnerabilities that have been deliberately implemented for educational and research purposes", I guess they might want to target vulnerabilities that have been implemented on purpose.

In case of code for educational and / or demonstration purposes that does not implement a vulnerability on purpose but rather inadvertently or approvingly accepting (e.g., maybe to keep things simple or to save effort), such a vulnerability might not be intended to be covered by 4.2.18.

They define "Vulnerability" as

An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.

And a "Product" as

A unit of software or hardware or both. “Product” is used broadly and includes services, open source projects, specifications, and other common terms such as: system, appliance, device, component, library, package, archive, and collection.

According to section 3.1 of the CNA rules, a CNA should define its scope. It depends on the EF CNA's definition of scope whether such code / repos are considered a "product in-scope" or not.

According to https://www.cve.org/PartnerInformation/ListofPartners/partner/eclipse EF CNA's scope is:

All projects hosted by the Eclipse Foundation as listed at https://www.eclipse.org/projects/ and services provided by the Eclipse Foundation to support open source projects as listed at https://www.eclipsestatus.io/

Based on that, code for educational and / or demonstration purposes that is part of a project hosted by EF might be seen as a product in scope.

https://blogs.eclipse.org/post/marta-rybczynska/reviewing-cve-process-and-cna-rules-40 states

An issue in a product developed deliberately for educational or research purposes only is not a vulnerability.

How does EF come to this statement? Is it based on rule 4.2.18 (which might be a misinterpretation) or something EF decided independently? Is it a limitation of EF CNA scope that has not been approved yet (CNA rule 3.1.2) or populated to https://www.cve.org/PartnerInformation/ListofPartners/partner/eclipse?

Is this in accordance with CNA rules? Is EF able to exclude vulnerabilities in such products (that are still in the scope of EF CNA) on its own discretion?

CNA rules state

4.2.2.1 CNAs SHOULD assign a CVE ID if:

the CNA has reasonable evidence to determine the existence of a Vulnerability (4.1), and

the Vulnerability has been or is expected to be Publicly Disclosed, and

the CNA has appropriate scope (3.1).

I think the issue reported in this vulnerability report has not been "deliberately implemented for educational and research purposes" but just for simplification and to save effort. It is a vulnerability according to the definition given in 4.1, it will be publicly disclosed and is in EF CNA scope, isn't it? One might argue that in accordance with CNA rules a CVE should be assigned.

So all in all, from my perspective, it boils down to the question whether the statement / rule "An issue in a product developed deliberately for educational or research purposes only is not a vulnerability." is in accordance / compliant with CNA rules or not.

If it is, everything is fine and I guess we are done. If not, you might need to check how to go on.

Please let me know about the next steps or what needs to be done before we can resolve / close this ticket and release it to the general public.

@neuschwa we have already updated the SECURITY.md file as we saw fit. Neither EDC, nor IdentityHub is a "product" by any definition, rather it is a framework. I said it several times and will say it one last time:

we will not assign a CVE for this issue

Please accept this decision as we will not argue the point any further.

This issue can therefor be closed. Making it public thereafter may be required or standard procedure by EF rules, I don't see any value in publicizing this moot discussion.

@neuschwa I agree that the scope of the Eclipse Foundation as CNA and its associated products is not fully clear wrt code how detected security vulnerabilities in code that is not ready yet for production use or is never intended for that should be handled.

So this is a process and we will take that input to improve in this regard. I believe the project made it clear what versions are supported and what not, unsupported versions not receiving a CVE for detected vulnerabilities.

This is clearly something that we should mentor our projects to do upfront to avoid discussions like that. Also keep in mind, that the EDC project is still in incubation phase, so that is something that we should also more prominently document to set expectations for security researchers.

On top of that we are very grateful for people like you to dig into possible vulnerabilities of our products / code and help improve the security of them as much as possible.

closed

made the issue visible to everyone