2

MITRE reorganized their assignment policy last year. They introduced a list of covered products and excluded other products from CVEs.

This year, they again opened up CVEs to all existing software, except open source software not in a list of covered products. Those are delegated to the DWF. But they also say that they are the CNA for "any other products not list on this page".

The DWF says that they only cover issues that are already public. This means that one would first have to disclose an issue without CVE before requesting a CVE, which seems to be going against the purpose of CVEs. I would assume that the purpose of the DWF is mainly to cover issues for which the researcher for some reason did not want to request a CVE themselves? And can it be assumed that the process of assigning CVEs to issues which are send to mailing lists (what MITRE called "Partial Coverage Sources") is discontinued with the establishment of the DWF (so there is no danger of double-assignment)?

Should I request a CVE via MITRE for issues in open-source software which are not yet public and not in the list of covered products, or should I publish them and afterwards request a CVE via DWF?

2
  • There is no "DWFP" it's just "DWF". Also we don't only cover issues that are public, we do embargoed CVEs as well, but in general only for people that have shown they can 1) make well formed requests and 2) actually get them out the door (I don't want embargoed CVEs sitting around forever). Source: am head of DWF.
    – Kurt
    May 11, 2017 at 18:17
  • @Kurt Fixed the DWF/DWFP issue, thanks. The form itself only mentions issues that are already public and specifically excludes embargoed CVEs, so I think that's - as you also said - a special case for a limited number of selected individuals then, and not an approach that is available in general.
    – tim
    May 11, 2017 at 18:37

2 Answers 2

2

My suggestion is to make sure the issue is fixed in the project, post it to Full Disclosure and then use that post to request the CVE.

2
  • That's what I assumed, but it really doesn't seem optimal, as the issue is then widely publicized without CVE, which might make it difficult to identify and distinguish from similar issues. And I thought that maybe the newly added phrase "as well as for any other products not list on this page" by MITRE might mean that this shouldn't be the process. But then, the list of covered products doesn't really make sense, so you may be right.
    – tim
    Mar 28, 2017 at 22:24
  • You could try to use the incident from the project's bug tracker to get the CVE and then publish to Full Disclosure with the CVE. I've never gotten a CVE for an open source project, just for my company's closed source products so I go straight to Mitre. It's easier than this. Mar 28, 2017 at 23:05
2

The best process I advise you to report a vulnerability of a vendor that is not a member of the CVE Number Authorities (CNA):

Request a CVE for the vulnerability that you found before notifying the vendor without sending an URL showing the detail of the vulnerability itself.

When the MITRE CVE receives a CVE request and does not have an URL reference, it registers CVE ID as "RESERVED".

** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

Then you notify the vendor/open-source project about the vulnerability and after their acknowledgement and patch the software you will have the vendor's own security advisory URL.

So, in turn, you will have enough information without being so technical as to commit so many users. Then just notify the URL to the corresponding CVE ID and the vulnerability becomes public.

Sometimes the vulnerability may not be published by MITRE CVE (cve.mitre.org) as fast as other sources, usually CNA members, e.g. IBM X-Force.

What is CNA?

CVE Numbering Authorities (CNAs) are organizations from around the world that are authorized to assign CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope, for inclusion in first-time public announcements of new vulnerabilities. These CVE IDs are provided to researchers, vulnerability disclosers, and information technology vendors.

Participation in this program is voluntary, and the benefits of participation include the ability to publicly disclose a vulnerability with an already assigned CVE ID, the ability to control the disclosure of vulnerability information without pre-publishing, and notification of vulnerabilities in products within a CNA's scope by researchers who request a CVE ID from them.

Reference: cve.mitre.org/cve/cna.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .