search

CVEProject / Board-Discussions

10 stars 15 forks source link

Review ID reservation, specifically how/why reservation is conveyed to consumers #15

Open zmanion opened 1 year ago

zmanion commented 1 year ago

Why are reserved IDs (the fact that an ID is reserved) ever shared with anyone other than the reserving CNA and the Secretariat?

When investigating "missing" assignments or publications (often RBPs), when I see a reserved ID, I immediately want to know who reserved it so I can go talk to them. Assigner is redacted, so I'd have to go ask the Secretariat, and this delay means I'm probably not going to bother.

Providing assigner (CNA) information on reserved IDs might lead to requests to the CNA asking about the content and timing of the not-yet-published CVE. This concern was brought up on a recent AWG call.

Is there any reason to expose reserved IDs to parties other than the reserving CNA?

zmanion commented 1 year ago

Debian does some analysis of Reserved But Public entries, this is beneficial to the Program:

https://security-team.debian.org/security_tracker.html

The Secretariat and possibly QWG will investigate further and brief the Board.

We don't want to turn off or turn away volunteer effort, but with the Services and JSON changes, the Debian tracker will need to update code, and the Program should reconsider how to handle RBP issues holistically.

todb commented 1 year ago

It seems to me that reserved CVE lists could, and should, be gated by at least an API key of the appropriate level. Root or CNA-LR or something. And then that list could be provided to a Debian maintainer list in a semi-private way if they're still into chasing RBPs for us.

zmanion commented 1 year ago

On TWG today, for cve.org lookup and search user stories, if record is reserved, return generic "ID not found" message.

This is a change from current behavior, which is to return a record with very limited information, only that the ID has been reserved by a CNA. The identity of the CNA is hidden (but is available/known to Secretariat and owning CNA).

At the time of this comment, the old reserved ID behavior:

https://www.cve.org/CVERecord?id=CVE-2023-34327

rpb_cveorg

https://cveawg.mitre.org/api/cve-id/CVE-2023-34327

rbp_api

A third way to access RBP status is bulk download, it has already been decided that bulk download does not include reserved IDs.

zmanion commented 1 year ago

Further documentation of this decision, for posterity.

A previously discussed option was to disclose the owning_cna to everyone in a reserved ID. This would have allowed someone to identify the CNA responsible when an RBP issue comes up. The decision was to not disclose owning_cna, and now not to disclose reserved status at all.

This leaves open the following scenario:

  1. An RBP happens, which is somewhat more common when multiple parties (suppliers, CNAs) are involved.
  2. Possibly the vulnerability is receiving public attention, possibly disclosed as a 0-day, being exploited in the wild. Thus, the need for CVE record content is urgent.
  3. Someone looks up the RBP and today, sees the RBP status, and in the future, sees nothing about the ID.
  4. Someone starts contacting Roots or the Secretariat to ask who owns the RBP.

Step 4 could be avoided by disclosing owning_cna in RPB records.

zmanion commented 1 week ago

The AWG is proposing to not change the current practice of conveying reserved status and redacting CNA identity, see https://github.com/CVEProject/cve-services/issues/1282#issuecomment-2471682199.

Leaving this issue open until TWG/Board render an opinion/decision.