Eclipse EDC: Consumer pull transfer token validation does not apply any rules (e. g., expiration check)

assigned to @neuschwa, @mspiekermann, @platzel, @mbarbero, and @mrybczyn

mentioned in issue vulnerability-reports#234 (closed)

My suggestion:

In Eclipse Dataspace Components, after 0.5.0 and before version 0.9.0, the ConsumerPullTransferTokenValidationApiController does not check for token validity (expiry, not-before, issuance date), which can allow the attacker to bypass the check for token expiration. The issue requires to have a dataplane configured to support http proxy consumer pull AND include the modules "transfer-data-plane". The affected code was marked deprecated in version 0.5.1 in favour of Dataplane Signaling. In 0.9.0 the vulnerable code has been removed.

The affected code was marked deprecated in version 0.5.1 in favour of Dataplane Signaling. (#28 (comment 2617484))

This statement might be incorrect. As far as I can see, the parts of org.eclipse.edc:data-plane-public-api were not marked as deprecated in version 0.5.1. They were marked as "deprecated since 0.6.0" and this deprecation annotation was added with the release of version 0.7.0. See this commit.

Btw. the ConsumerPullTransferTokenValidationApiController from org.eclipse.edc:transfer-data-plane seems to not have been marked as deprecated yet.

Can you please check and adjust the suggested text accordingly?

thank you for your input, we'll take it under advisement.

What about:

In Eclipse Dataspace Components, after 0.5.0 and before version 0.9.0, the ConsumerPullTransferTokenValidationApiController does not check for token validity (expiry, not-before, issuance date), which can allow the attacker to bypass the check for token expiration. The issue requires to have a dataplane configured to support http proxy consumer pull AND include the modules "transfer-data-plane". The affected code was marked deprecated from the version 0.6.0 in favour of Dataplane Signaling. In 0.9.0 the vulnerable code has been removed.

fine by me.

@mrybczyn this wording has been approved by the EDC Committers, so we're good to go.

fine for me as well

changed the description

My proposal for CVSS is CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/RE:L/U:Green (https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/RE:L/U:Green) which gives CVSS Score of 5.3 (Medium)

The little load impact is not causing any security problem, so there is only impact on the "subsequent" system (ones that can be accessed with the missing authentication)

OK for me, but I would put Privleges Required (PR) to High, because an attacker must have gone through a contract negotiation, transfer process, and successful data transmission setup beforehand. This also requires them to be a recognized member of a dataspace.

https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/RE:L/U:Green

@mrybczyn The CVE score https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/RE:L/U:Green has been approved by the EDC Committers, so we're good to go.

I would agree on the "VA:N" if only considering the ConsumerPullTransferTokenValidationApiController as part of the vulnerable system. Then the additional load on the connector might be considered as negligible as it is just checking (and falsely confirming) the token once per (unauthorized) request. However, there is additional the "data-plane-public-api" (the endpoint exposed for consumers to pull the data) that I consider to be part of the vulnerable system as well. Internally, that endpoint queries the data source (subsequent system) and forwards the response to the consumer in a synchronous way. It is possible that the data is a large file / dataset and that it takes some time to retrieve the data and send it as a response to the requester. I think this might occupy a non-negligible amount of resources of the vulnerable system / connector / dataplane (network connections, bandwith, IO, processor cycles).

Regarding the "SA:N", I disagree. I recommend to consider keeping a higher rating (low or high) for "SA". It depends on the data source or data in use. The data could be a very large file that is retrieved; occupying network bandwith, IO, and processor cycles of the data source / subsequent system on each access that will not be availble to serve the requests of authorized entities. Effectivly occupying/consuming ressources and reducing the performance of the subsequent system. In case of using an API as data source and proxying/passing through the request method and request body to the subsequent system, it depends on the logic that is behind the API. One might expose access to a service that involves heavy calcualtions or memory usage, occupying these resources without permission and degrading the availability of the service for legitimate users. From my point of view, there might be an non-negligible impact to the availability to the subsequent system.

Please consider more than "N" for "VA" and "SA".

OK for me, but I would put Privleges Required (PR) to High, because an attacker must have gone through a contract negotiation, transfer process, and successful data transmission setup beforehand. This also requires them to be a recognized member of a dataspace. (#28 (comment 2617841))

I disagree on this. "PR" is described as

This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

"High" rating is described as

The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system’s settings and files.

The vulnerable system is the connector or dataplane at the provider side. To exploit the vulnerability, one does not need such a high level of privileges to the vulnerable system.

Once an eligible data space participant negotiated a contract and started a transfer process, a Token is created and pushed to the consumer-side subsequent system (everything is fully automated) and can be used there beyond its expiration for "pulling the asset". From my point of view, an attacker can do the attack with a rather "normal" level of privileges (i.e., just a normal data space participant that has no "high" privileges to the vulnerable system). An attacker could be a normal employee at the consumer-side company that has normal access level to subsequent systems at the consumer side (e.g., user keeps clicking on a "refresh data" or "query" button beyond the expiration time) or anyone else that got in possession of the token.

But to do so, one does not need some kind of "high" privileges to the vulnerable system.

Please consider less than "H" for "PR".

thank you for your input, it has been taken into consideration. The decision of the EDC committers has been made.

ad "VA:N" and "SA:N": this is an incorrect assessment. A Denial-of-service attack as you describe it can be performed even if this vulnerability didn't exist, i.e. with a valid token. The fact that it is possible with an expired/revoked token does change that. It is the responsibility of the provider organization to put appropriate infrastructure, such as API gateways, rate-limiters, etc. in place.

ad "PR:H": This assessment is incorrect as well. The highest level of access anyone (including an attacker) could ever obtain through the systems described here is read access on the provider's data. The definition of "PR:L" states

an attacker with low privileges has the ability to access only non-sensitive data

Taking these definitions too literally is not productive. But again, access to the provider's data is absolutely sensitive, and it is also the highest privilege obtainable.

[edit]: on a personal note I would kindly ask you to make your statements more concise. Writing walls-of-text is not productive.

regarding "VA:N" and "SA:N"

The difference is that valid tokens can be used to legitimately occupy/use/consume the resources. While being able to occupy/use/consume resources using expired tokens is an illegitimate resource occupation that can have an impact the availability of the system for legitimate users. Therefore I do not fully agree on the "N" rating.

regarding "PR:H"

The highest level of access anyone (including an attacker) could ever obtain through the systems described here is read access on the provider's data

From my point of view, this is incorrect. Consumer pull cannot only be used to read provider's data from their subsequent systems. It can be used (and is used by some) to expose an API of the provider's subsequent system that accepts POST requests to modify data in the subsequent system at the provider side. Therefore we have the "SI:H".

Nevertheless, PR is about the privileges required to exploit the vuln, not about what one can do or access once they successfully exploited the vuln. I could understand to pick "PR:H" if an attacker would require privileged access to the vulnerable system (e.g., see config files, access management api, ssh to the machine, read vault content, or logs or so). But this is not the case here. An attacker does not need any privileged access to the vulnerable system prior to being able to exploit the vuln. An attacker only needs a Token; and to get one does not require any sort of high privileged access to the vulnerable system at the provider side. Therefore I do not agree on the "H" rating as less privileges are sufficient to successfully exploit the vuln.

I can only draw your attention to my point of view. Ultimately, however, it is your responsibility to make an appropriate assessment.

Maybe @mrybczyn can double check the CVSS and provide guidance if necessary.

What operations are available on the provider's backend is completely irrelevant, as it does not pertain to this vulnerability. In addition, a POST request does by no means imply that data is written.

But like I said, you've made your point, the EDC committers just happen to disagree.

What operations are available on the provider's backend is completely irrelevant, as it does not pertain to this vulnerability.

I disagree with that. It is relevant for the Subsequent System Impact Metrics that is part of CVSS 4.0.

In addition, a POST request does by no means imply that data is written.

I disagree with that. POST is by definition a non-idempotent and non-safe operation. "A POST request is typically sent via an HTML form and results in a change on the server". Therefore, it can (and in RESTful-APIs most commonly does) store/write data at the target system. => There are POST requests that do not write any data but there can be POST requests that do write data / modify the state of the target system. From my experience, the latter case is the more common one.

Nevertheless, discussing this detail does not add anything relevant to the discussion as no one questioned "SI:H" so far.

The discussion should be about "VA", "SA" and "PR" as our assessments diverge in these aspects.

I don't think we're getting anywhere here. Both sides have presented their point of view.

I would like to ask the Eclipse Foundation Security Team (@mrybczyn / @netomi) to review the CVSS and mediate.

The decision is up to the committers, and we've made that decision, thanks anyway.

Let me give my opinion. For me there is no Availability score (VA/SA) because the issue does not amplify the traffic (eg. generate two message from one) nor add additional load. The load is the same as if it were in case of a correctly authorized message.

As for PR, I tend to "PR:L" because the attacker doesn't have to be an administrator, not have access to all the configuration files. However, I'm OK for "PR:H" if the Project team prefers this setting. There is no important change in CVSS (5.0 vs 5.3).

Please note, from the process side, that other parties might add their own CVSS scoring after ours (for example NVD often does re-scoring) and slight differences in assignments are pretty common.

@platzel is it acceptable for you?

@mrybczyn The description on the CVSS site is not really transferrable, and the attacker is already at the highest attainable authorization. Thus, the team would like to go with "PR:H"

So yes, this is OK for me (us, really).

assigned to @netomi

changed due date to September 10, 2024

added cverequested label

Reserved the CVE ID: CVE-2024-8642

added cvereserved label and removed cverequested label

I prepared the following CVE, please take a look if everything is as expected. Information about the CVE was a bit spread out so I had to collect the information and I hope I did not miss anything:

Hi @netomi thank you for taking care of this.

I noticed that you slightly changed the wording about the affected versions in the beginning of the description text to clarify that version 0.5.0 is affected as well ("after and including")

Besides of that, the description text is the one that has been approved by the EDC Committers.

There is a typo in the text: "AND include the modules" (should either be singular or one should name the "data-plane-public-api" module as well).

The affected versions are: 0.5.0 (including) - 0.9.0 (excluding).

As long as there will be no new 0.8.Z release, through 0.8.1 for the end of the version range is correct. But a 0.8.2 release (in case such a release might ever be released) might be affected as well.

How about using "affected from 0.5.0 before 0.9.0" for the product status following this guide? (but I'm fine with the current wording as well)

Maybe a similar terminology could be used for the description text as well (i.e., "from version 0.5.0 and before version 0.9.0" or so instead of "after and including ... and before ...") to make it more clear. (but I'm fine with the current wording as well)

The CVSS vector and score might be missing (at least they are not depicted). A discussion about the CVSS can be found in this thread and its comments: #28 (comment 2617839)

Should we add a reference to the 0.9.0 release in the CVE entry as well?

Do you need anything else? From me or from the EDC team?

so the only difference from the approved text I made was about the formulation about the inclusion of v0.5.0. It did not make sense to me to state "after 0.5.0" which makes it unclear what the first affected version is, could be 0.5.1 or 0.6.0 so I assumed that to be a mistake. I should have raised that point before populating the CVE entry.

You are right about the affected versions, I changed that to < 0.9.0.

The CVSS score is missing in the preview of the tool to populate CVE entries, but it has been added as agreed on.

I will add a reference to the 0.9.0 release as well, I missed that.

so the only difference from the approved text I made was about the formulation about the inclusion of v0.5.0. It did not make sense to me to state "after 0.5.0" which makes it unclear what the first affected version is, could be 0.5.1 or 0.6.0 so I assumed that to be a mistake. I should have raised that point before populating the CVE entry.

I'm glad you noticed our unfortunate wording and took action to make it more clear for people to capture that version 0.5.0 is affected as well.

You are right about the affected versions, I changed that to < 0.9.0.

After thinking about it again, I'm not sure how to express the product status / affected versions correctly. With EDC release 0.9.0 the whole transfer-data-plane module was removed, i.e., there is no version 0.9.0 of transfer-data-plane that is no longer vulnerable (as there is no 0.9.0 version of that module at all). Can we state < 0.9.0 if there is no version 0.9.0? Or are we referring to the EDC in general here?

the sentence starts with "In Eclipse Dataspace Components..." and EDC does not release individual modules with individual versions. Therefor one particular version denomination always refers to the entire set of components. I think that - again - you are splitting hairs, which is not productive.

updated preview

Thank you for considering my comments.

Please feel free to submit / publish the CVE as it is.

Published at https://www.cve.org/CVERecord?id=CVE-2024-8642.

made the issue visible to everyone

closed

added cvepublished label and removed cvereserved label

Eclipse EDC: Consumer pull transfer token validation does not apply any rules (e. g., expiration check)

Basic information

Tracking

Child items ...

Activity