Vendors, Products and Versions are totally messed up

[cookiengineer]

Hey there,

in the cvelist, all vendors and products and their versions are totally messed up.

First off, there seem to be more than one notation for the meaning of "n/a" (aka null). So far I've identified these notations: n/a, * n/a *, *** n/a ***, NONE, None, none, no, null, [UNKNOWN], [Unknown], Unknown.

Additionally, all vendors and products are messed up. Sometimes there's the product field containing the actual versions that are affected in a comma separated list. Sometimes the Vendor is redundantly marked e.g. as Example, Inc and Example Corporation and Example. Siemens alone has more than 10 different notations.

The versions themselves are a whole other story, because most of them are also totally invalid. Even when there's a lessThan field set, sometimes the value of it is set to None. It gets even more ridiculous when the same CVE has two different affected versions which logically contradict each other.

[chandanbn]

These are good points to provide guidance on in the best practices doc CVEProject/cve-schema#241

[sei-vsarvepalli]

Hello @cookiengineer

Do you have the scripts/tools you used for this analysis that you are wiling to share? Are you able to provide perhaps the list of big offending CNA's that provide such contradictory data? This may help us write better guidance and eventually pursue more programatic validations to keep driving quality into the collected CVE records.

Thanks
Vijay

[itipsai]

Hello.

I have the same issue. For example CVE-2021-41617 in old format file https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-2021.json.zip has detailed list of affected products:

  "description" : {
    "description_data" : [ {
      "lang" : "en",
      "value" : "sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user."
    } ]
  }
},
"configurations" : {
  "CVE_data_version" : "4.0",
  "nodes" : [ {
    "operator" : "OR",
    "children" : [ ],
    "cpe_match" : [ {
      "vulnerable" : true,
      "cpe23Uri" : "cpe:2.3:a:openbsd:openssh:*:*:*:*:*:*:*:*",
      "versionStartIncluding" : "6.2",
      "versionEndExcluding" : "8.8",
      "cpe_name" : [ ]
    } ]
  }, {
    "operator" : "OR",
    "children" : [ ],
    "cpe_match" : [ {
      "vulnerable" : true,
      "cpe23Uri" : "cpe:2.3:o:fedoraproject:fedora:33:*:*:*:*:*:*:*",
      "cpe_name" : [ ]
    }, {
      "vulnerable" : true,
      "cpe23Uri" : "cpe:2.3:o:fedoraproject:fedora:34:*:*:*:*:*:*:*",
      "cpe_name" : [ ]
    }, {
      "vulnerable" : true,
      "cpe23Uri" : "cpe:2.3:o:fedoraproject:fedora:35:*:*:*:*:*:*:*",
      "cpe_name" : [ ]
    } ]
  }, {

In new version of CVE, which is at https://github.com/CVEProject/cvelistV5/blob/main/cves/2021/41xxx/CVE-2021-41617.json, cpe information as well as list of affected products is empty.

    },
        "descriptions": [
            {
                "lang": "en",
                "value": "sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user."
            }
        ],
        "affected": [
            {
                "vendor": "n/a",
                "product": "n/a",
                "versions": [
                    {
                        "version": "n/a",
                        "status": "affected"
                    }
                ]
            }
        ],

Could you please clarify whether you plan to transfer information about affected products to a new format and if so, when.
If the transfer is not planned, do I understand correctly that this information will be lost for the new format?

[xiconfjs]

Same issue here with many CVEs where JSON 4.0 has way more detailed information, just one example:

• CVE-2024-28535
  • no CWE-XXX type
  • no cpe/affected information
  • no impact/metric information

JSON 4.0:

{
    "cve" : {
      "data_type" : "CVE",
      "data_format" : "MITRE",
      "data_version" : "4.0",
      "CVE_data_meta" : {
        "ID" : "CVE-2024-28535",
        "ASSIGNER" : "cve@mitre.org"
      },
      "problemtype" : {
        "problemtype_data" : [ {
          "description" : [ {
            "lang" : "en",
            "value" : "CWE-787"
          } ]
        } ]
      },
      "references" : {
        "reference_data" : [ {
          "url" : "https://github.com/abcdefg-png/IoT-vulnerable/blob/main/Tenda/AC18/fromAddressNat_mitInterface.md", 
          "name" : "https://github.com/abcdefg-png/IoT-vulnerable/blob/main/Tenda/AC18/fromAddressNat_mitInterface.md",
          "refsource" : "",
          "tags" : [ "Exploit", "Third Party Advisory" ]
        } ]
      },
      "description" : {
        "description_data" : [ {
          "lang" : "en",
          "value" : "Tenda AC18 V15.03.05.05 has a stack overflow vulnerability in the mitInterface parameter of fromAddressNat function."
        } ]
      }
    },
    "configurations" : { 
      "CVE_data_version" : "4.0",
      "nodes" : [ {
        "operator" : "OR",
        "children" : [ ],
        "cpe_match" : [ {
          "vulnerable" : true,
          "cpe23Uri" : "cpe:2.3:o:tenda:ac18_firmware:15.03.05.05:*:*:*:*:*:*:*",
          "cpe_name" : [ ]
        } ]
      } ]
    },
    "impact" : {
      "baseMetricV3" : {
        "cvssV3" : {
          "version" : "3.1",
          "vectorString" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "attackVector" : "NETWORK",
          "attackComplexity" : "LOW",
          "privilegesRequired" : "NONE",
          "userInteraction" : "NONE",
          "scope" : "UNCHANGED",
          "confidentialityImpact" : "HIGH",
          "integrityImpact" : "HIGH",
          "availabilityImpact" : "HIGH",
          "baseScore" : 9.8,
          "baseSeverity" : "CRITICAL"
        },
        "exploitabilityScore" : 3.9,
        "impactScore" : 5.9
      }
    },
    "publishedDate" : "2024-03-12T13:15Z",
    "lastModifiedDate" : "2024-03-21T20:58Z"
  }

JSON 5.0:

{
    "dataType": "CVE_RECORD",
    "dataVersion": "5.0",
    "cveMetadata": {
        "state": "PUBLISHED",
        "cveId": "CVE-2024-28553",
        "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
        "assignerShortName": "mitre",
        "dateUpdated": "2024-03-12T12:47:50.996910",
        "dateReserved": "2024-03-08T00:00:00",
        "datePublished": "2024-03-12T00:00:00"
    },
    "containers": {
        "cna": {
            "providerMetadata": {
                "orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca",
                "shortName": "mitre",
                "dateUpdated": "2024-03-12T12:47:50.996910"
            },
            "descriptions": [
                {
                    "lang": "en",
                    "value": "Tenda AC18 V15.03.05.05 has a stack overflow vulnerability in the entrys parameter fromAddressNat function."
                }
            ],
            "affected": [
                {
                    "vendor": "n/a",
                    "product": "n/a",
                    "versions": [
                        {
                            "version": "n/a",
                            "status": "affected"
                        }
                    ]
                }
            ],
            "references": [
                {
                    "url": "https://github.com/abcdefg-png/IoT-vulnerable/blob/main/Tenda/AC18/fromAddressNat_entrys.md"
                }
            ],
            "problemTypes": [
                {
                    "descriptions": [
                        {
                            "type": "text",
                            "lang": "en",
                            "description": "n/a"
                        }
                    ]
                }
            ]
        }
    }
}

[sei-vsarvepalli]

Redhat PSIRT team has been also helping us with this work and have created a tool cvelint that is helpful in https://github.com/mprpic/cvelint/tree/main with produces a cvelint-action repository to capture these errors using GitHub Actions. https://github.com/jgamblin/cvelint-action

Please explore these tools that also is trying to help improve quality in the CVE data specifically in fields such as "affected products" as mentioned here.

[xiconfjs]

Redhat PSIRT team has been also helping us with this work and have created a tool cvelint that is helpful in https://github.com/mprpic/cvelint/tree/main with produces a cvelint-action repository to capture these errors using GitHub Actions. https://github.com/jgamblin/cvelint-action

Please explore these tools that also is trying to help improve quality in the CVE data specifically in fields such as "affected products" as mentioned here.

Ok, for the CNA "mitre" I ran the tool for 2024s CVEs and got 867 cases with Invalid version string: "n/a" (at "containers.cna.affected.#.versions.#.version"). What to do now? Is there a way to report these? Because we have to fix these before the official [1] [2] termination of the legacy list.

[1] "(...) They will no longer be updated after June 30, 2024."
[2] https://www.cve.org/Media/News/item/blog/2024/03/12/Phase-3-Deprecation-of-Legacy-Downloads-Underway

[sei-vsarvepalli]

Hello @xiconfjs

The termination of legacy list is not relevant for this issue, as the API based feed will also provide the same data anyway. Currently the way to use cvelint project is to filter out data that is incomplete when consuming CVE data using tools. As far as the longer-term fix (of updating these records and forcing better input schema validation), there is some work going on the CVE Quality Working Group (QWG) https://www.cve.org/ProgramOrganization/WorkingGroups to try to move the needle forward in better quality of CVE data. The documents we are writing in the various ways also are helping CNA's be more responsible for providing quality data in their CVE records.

Hope that makes sense!

[xiconfjs]

(...) as the API based feed will also provide the same data anyway. (...) there is some work going on the CVE Quality Working Group (QWG) (...) to try to move the needle forward in better quality of CVE data. (...)

Hi @sei-vsarvepalli,

thank you for trying to shine some light into this situation. But as presented before (#6 (comment)) there are differences in the pure data between the legacy data source (https://www.cve.org/Downloads#legacy-format) which is provided in JSON 4.0 syntax and the new data source (https://github.com/CVEProject/cvelistV5) provided in JSON 5.0. And as you can see this example CVE (CVE-2024-28553) was published on 2024-03-12, so no old data which didn't get migrated correctly. How does such a discrepancy come about?

Thanks
@xiconfjs

[xiconfjs]

(...) as the API based feed will also provide the same data anyway. (...) there is some work going on the CVE Quality Working Group (QWG) (...) to try to move the needle forward in better quality of CVE data. (...)

Hi @sei-vsarvepalli,

thank you for trying to shine some light into this situation. But as presented before (#6 (comment)) there are differences in the pure data between the legacy data source (https://www.cve.org/Downloads#legacy-format) which is provided in JSON 4.0 syntax and the new data source (https://github.com/CVEProject/cvelistV5) provided in JSON 5.0. And as you can see this example CVE (CVE-2024-28553) was published on 2024-03-12, so no old data which didn't get migrated correctly. How does such a discrepancy come about?

Thanks @xiconfjs

I have to clarify something...the "old" JSON data source I was referring to wasn't sources from cve.org @ mitre but from nvd @ nist. So, my question would have to be rephrased: Why is does the nvd higher quality data? Or isn't NVD sharing with cve.org?

[adulau]

The original NVD data source (the famous JSON that they will decommission at some point) includes much more details about vulnerable_configuration than the current v5 from MITRE and even the API of NVD don't have any more the data. Let's take CVE-2010-4444 as an example.

• NIST/NVD details CVE-2010-4444
  includes CPEs cpe:2.3:a:oracle:opensso:7:*:*:*:*:*:*:*
• MITRE CVE-2010-4444
  CPE is not there (affected product is n/a) - similar sources as vulnerability-lookup
• Present in old cve-search CVE-2010-4444 (using original JSON dump)
• Not present in vulnerability-lookup CVE-2010-4444 (Using NVD API and GitHub CVElist)

We really think there is a major issue with the new NVD API which basically not including the original data for the vendors, products and versions mentioned in the original issue and by others in this issue.