requesterUserId becomes public inconsistently; possible information leak

[ElectricNroff]

If a CVE Record becomes public as a result of a user using the POST /cve/{id}/cna endpoint, then that user's UUID is stored in the requesterUserId field. However, if a CVE Record becomes public as a result of a user using the POST /cve/{id}/reject endpoint, then that user's UUID is not stored in the requesterUserId field.

The best solution may be to ensure that CVE Services never includes the requesterUserId field in a CVE Record. Today, JSON 4 CVE Records are publicly attributed only to a CNA; they are not publicly attributed to a specific user within a CNA. The schema documentation says:

cve-services/src/middleware/5.0_bundled_schema.json

Lines 464 to 466 in b083cfe

	"requesterUserId": {
	"$ref": "#/definitions/userId",
	"description": "The user that requested the CVE identifier."

cve-services/src/middleware/5.0_bundled_schema.json

Lines 86 to 88 in b083cfe

	"userId": {
	"description": "A UUID for a user participating in the CVE program. This UUID can be used to lookup the user record in the user registry service.",
	"$ref": "#/definitions/uuidType"

but the privacy policy and access-control policy of the user registry service have not yet been discussed much by the CVE community.

If the user registry service does not exist, then public consumers of CVE Records cannot directly see personal information about a requester (e.g., an email address), but can see the requester pattern. This allows correlation attacks that can result in unwanted information leaks. Because risk management of correlation attacks hasn't yet been discussed with CNAs, it is best to block these attacks in the initial launch of CVE Services 2.x. (Controls on information can become looser in the future if desired, but once the information leaks, it can't be taken back.)

For example, some CNAs (e.g., researcher CNAs, and vendor CNAs who assign for internally discovered vulnerabilities) might have an internal business practice in which all staff members have CVE Services user accounts, and each staff member reserves a CVE ID for a vulnerability that they personally discover. Also, when the vulnerability is publicly disclosed in an advisory, they may have valid reasons to credit the discoverer personally in some cases, but simply credit the CNA organization in other cases. (For example, if a vendor sometimes makes legal threats against researchers, a researcher CNA organization might conclude that it is best to omit the name of the specific researcher.) Any CNA might be relying on the CVE ID object (in CVE Services) to store information about which person discovered which vulnerability. That CVE ID information has never been publicly accessible. However, the requester pattern would suddenly become public for all CVE Records that become public after the CVE Services 2.x launch. For example, UUID X might appear in the requesterUserId field of the CVE-2022-90001, CVE-2022-90051, and CVE-2022-90071 CVE Records. CVE-2022-90001 and CVE-2022-90051 might have associated security advisories naming alice@example.com as the discoverer; however, CVE-2022-90071 might only name the Example Organization as the discoverer. By looking at the pattern, an adversary may be able to infer that alice@example.com is UUID X, and thus was the researcher who discovered CVE-2022-90071 and made it public (which may have been contrary to the vendor's wishes). Especially if such a pattern continued across dozens or hundreds of vulnerabilities, the adversary might have high confidence that alice@example.com was behind CVE-2022-90071, even though the CNA never wanted that fact to be public.

Possible solutions include:

1. Go with the above proposal in which requesterUserId will not be placed into any CVE Record until the CNA community discusses the user registry and privacy implications.
2. Inform CNAs that, if they didn't want the requester pattern to be public, they should not have had multiple requesters, and they should avoid having multiple requesters in the future. Also, offer an API for them to change the requester information in their current collection of CVE ID objects.
3. Ignore privacy issues and make the requesterUserId field public for both rejected and published records. A possible justification is that any CNA who carefully read the schema documentation would have anticipated that requesterUserId was a possible information leak, and may have already implemented a workaround.

[jdaigneau5]

We will implement proposed solution 1.