Andrey Lukashenkov of Vulners
is one of the best vulnerability researchers around; he has been an active
participant in the OWASP Vulnerability Database Working Group. He posted a very
helpful (and very relevant) comment on my
post from yesterday on LinkedIn (whenever I write a post in this blog, I
post a link to it on LI). Here is what he said, with some amplification (enrichment?
😊) by me:
I wanted to show an example to illustrate the problem and
show that even before the collapse, NVD-provided “enrichment” was sometimes
misleading and subpar. Let's look at CVE-2023-32019 regarding MS Windows Server
2022:
Here is the CVE record in the NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-32019#match-12900863.
Here is the CPE name for the software in question, which appears
in the NVD’s CVE record:
cpe:2.3:o:microsoft:windows_server_2022:-:*:*:*:*:*:*:*
If you’re experienced interpreting CPEs, you may recognize
that the NIST (NVD) staff member who created the CPE name didn’t include a
version string in it. Therefore, since this CPE name is listed as vulnerable to
CVE-2023-32019, it (presumably unintentionally) asserts that every version of
Windows Server 2022 is affected by that vulnerability.
This means that, if you query the NVD for any Windows Server
2022 version, including the one released yesterday, it will always appear to be
affected by the same CVE, even though it’s very doubtful that it is.
The CVE Numbering Authority (or CNA. For a discussion of CNAs
and what they do, see yesterday’s post) for Microsoft software is…get ready for
it…Microsoft. Microsoft is one of the best CNAs out there, regarding the
completeness of the information provided. Their CPE name is
cpe:2.3:o:microsoft:windows_server_2022:10.0.20348.1787:*:*:*:*:*:*:*.
Microsoft’s CVE record on this
vulnerability lists 11 Microsoft products, each of which has an affected
version range. For Windows Server 2022, Microsoft lists two version ranges: “affected
from 10.0.0 before 10.0.20348.1787” (which matches what’s in their CPE name)
and “affected from 10.0.0 before 10.0.20348.1784”. Note these are almost
identical ranges.
I don’t know why there are two ranges, but the point is these
were presumably on the CVE report that the NIST/NVD person was looking at when they
created the CPE name. Yet, the NVD CVE
record that the person created doesn’t list any version range for Windows
Server 2022.
That omission means every version of Windows Server 2022
appears to be vulnerable to CVE-2023-32019 – so a lot of software security
professionals will waste a lot of time searching for this vulnerability on Windows
Server 2022 versions that aren’t vulnerable at all. Moreover, it’s inevitable
that a lot of end user organizations will reach out to Microsoft, demanding
that their non-vulnerable version be patched – causing a lot of unnecessary
headaches for help desk staff…all because an NVD staff member (or contractor)
skipped a vital step.
With a closer look, NVD data turns out to be noisy. There
isn't much value in a CPE like this. If you use it, the number of false
positives will be staggering.
Andrey’s concluding advice is, “Wherever
you get your CVE data, you want them with both the NVD and CNA pieces[i] combined and
cross-checked.” No kidding. Thanks for this great example, Andrey!
Of course, I’m not trying to say
in this post that the CNAs don’t make mistakes and the NVD always does. But the
point is that the CNA is often the organization that developed the vulnerable
software; they should be the authoritative source for information about that
vulnerability. Yet, as I mentioned in yesterday’s post, the NVD resists
providing information on how they create CPE names – so there’s no way for anyone
else to learn from their mistakes. They clearly want to keep creating CPE
names, since, frankly speaking, they don’t add a lot of other value to the data
in the NVD (which is all originally created by the CNAs, who are part of
CVE.org. The NVD staff often overrides the CNA’s CVSS score, even though the CNA
should be in charge of that as well, for the same reason as they should be in
charge of the CPE name).
Which reminds me of something that
was said in this week’s OWASP Vulnerability Database Working Group meeting: After
hearing a litany of the NVD’s failings, I asked if anyone could name one way in
which the NVD is helping the situation. The Director of Product Security
for a large software developer (who until recently was a big defender of the
NVD) gave a one-word answer: “Obstruction”.
I was going to title yesterday’s
post “Patience with the NVD is wearing thin.” Maybe I should have stuck with
that title.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. If you would like to comment on what you have
read here, I would love to hear from you. Please email me at tom@tomalrich.com.
I lead the OWASP SBOM Forum, which works to understand and address issues like what’s
discussed in this post; please email me to learn more about what we do or to
join us. You can also support our work through easy directed donations to OWASP,
a 501(c)(3) nonprofit. Email me to discuss that.
My book "Introduction to SBOM and VEX" is now available in paperback and Kindle versions! For background on the book and the link to order it, see this post.
[i] By
“CNA piece”, I assume Andrey’s referring to the CVE record in CVE.org, since
that doesn’t yet have the “benefit” of being “enriched” by the NVD. It’s just
displays what the CNA included in their CVE report.
No comments:
Post a Comment