Home What is a CVE?
Post
Cancel

What is a CVE?

Vicente Herrera on Dec 6, 20212021-12-06T05:20:00+01:00
Updated Jun 282023-06-28T08:15:03+02:00 13 min read
Cyberpunk 2077 car hijack

You are playing Cyberpunk 2077, and on the introductory mission, you have to steal a car. After using an electronic tool first to open its door, you get inside, and while the hijack takes place, a message appears on the sophisticated onscreen display of the car:

RUN:EXPLOIT.CVE-0322.B/055BCCAC9FEC/LOADING

That sounds familiar, isn’t it? You are trying to figure out the numbers written there, but immediately Jackie appears for the first time, and interrupts you.

You have seen it before on many occasions where a new vulnerability is discovered, and while some may have a fancy name as “SMBGhost” or “BlueKeep”, they are always accompanied by a sequence identifier like CVE-2020-0796 or CVE-2019-0708.

For example, scanning the container image node:latest at the time of writing this post with an open-source vulnerability scanner like Trivy or Clair; or a commercial one like Sysdig or Aqua, you see many entries like:

LibraryVulnerability IDSeverityInstalledFixedTITLE
python3.9CVE-2021-29921CRITICAL3.9.2-1 python-ipaddress: Improper input validation of octal strings
curlCVE-2021-22945CRITICAL7.74.0-1.3 curl: use-after-free and double-free in MQTT sending
ansi-regexCVE-2021-3807HIGH3.0.05.0.1, 6.0.1nodejs-ansi-regex: Regular expression denial of service (ReDoS) matching ANSI escape codes

What does CVE stand for?

The Common Vulnerability and Exposures (CVE) program was launched in 1999 by MITRE. Their intent as described in their website is:

The mission of the CVE Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog. The vulnerabilities are discovered then assigned and published by organizations from around the world that have partnered with the CVE Program. Partners publish CVE Records to communicate consistent descriptions of vulnerabilities. Information technology and cybersecurity professionals use CVE Records to ensure they are discussing the same issue, and to coordinate their efforts to prioritize and address the vulnerabilities.

At the current date, the new cve.org website holds information on 165,047 vulnerabilities; the old cve.mitre.org is still used for downloading and keyword searching. The website cvedetails.com is also nice for searching, as well as the National Vulnerability Database (NVD) (more on that later).

The CVE program is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA), available to the public and free to use. CVE and its logo are also registered trademarks of The MITRE Corporation.

CVE IDs

CVE IDs are used to univocally identify registered vulnerabilities. Organizations that assign CVE are called CVE Numbering Authorities (CNAs).

A CVE ID takes the form of:

CVE-<year>-<id number>

That makes it easy to know if a given vulnerability is recent or very old. For example:

  • CVE-2020-0796, aka “SMBGhost”, registered in the year 2020.
  • CVE-2007-0029, aka “Excel Malformed String Vulnerability”, registered in the year 2007

This doesn’t mean the vulnerability didn’t exist earlier, that is the year where it first was documented. By the way, that means that the CVE shown in Cyberpunk 2077 should have started with CVE-2077. Well, add that to the list of problems with that game.

CVE record

A CVE ID has descriptive data associated with the vulnerability that is called CVE record. This can be in one of the following states:

  • Reserved: The initial state for a CVE Record, can just contain an identification number (CVE ID).
  • Published/Public: Data published for public use. Must contain CVE ID, prose description, and at least one public reference.
  • Rejected: If the CVE ID and associated CVE Record should no longer be used, it is placed in this state, so that users can know it is invalid.

For example, the CVE record for CVE-2017-5638 includes the following information:

  • Description: The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, as exploited in the wild in March 2017 with a Content-Type header containing a #cmd= string.
  • State: Public
  • Vendors, products & versions:
    • Vendor: Apache Software Foundation
      • Product: Apache Struts
        • Versions Affected:
          • 2.3.x before 2.3.32
          • 2.5.x before 2.5.10.1
  • Reference links: (a long list of references with additional information)

MITRE ATT&CK tactics and techniques are sometimes referenced in the description of the vulnerability, and are planned to be formaly added to CVE records soon. Learn more about them in my blog post “Introduction to MITRE ATT&CK”

NVD

The National Institute of Standards and Technology (NIST) maintains the National Vulnerability Database (NVD) since 2005. It is built upon and fully synchronized with the CVE list, any update on CVE website appears immediately in the NVD. But it also provides enhanced information such as fix, severity score, and impact ratings. NVD also provides advanced searching features such as by OS; by vendor name, product name, and/or version number; and by vulnerability type, severity, related exploit range, and impact.

The NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes databases of security checklist references, security-related software flaws, misconfigurations, product names, and impact metrics.

The NVD is also sponsored by CISA (as is the CVE program), and is also available to the public and free to use.

An example NVD entry for a CVE id is the CVE-2020-0796 NVD entry:

CVE-2020-0796

The reference links provided can classified as Third Party Advisory, VDB Entry (Vulnerability Database Entry), Exploit, Mailing List, Mitigation, Release Notes, Patch, US Government Resource among others. Of special interest is the Exploit category that indicates that there is a known exploit for the vulnerability.

CPE (Common Platform Enumeration) and SWID (Software Identification) are used to identify the software and version where a vulnerability has been found.

NVD also includes references to the Common Weakness Enumeration (CWE) by MITRE when describing the vulnerability.

When people talk about the information “on a CVE”, they usually mean the extended information available on the NVD.

CVSS

The Common Vulnerability Scoring System (CVSS) is a way to assess the severity of vulnerabilities. Two versions of this standard are used right now, CVSS V2 and V3.1.

CVSS V2 severity score ranks them as Low (0.0-3.9), Medium (4.0-6.9) or High (7.0-10.0). It also includes information about Base metrics (Access Vector, Access Complexity, Authentication) and Impact metrics (Confidentiality, Integrity, Availability) which combines in a formula for the base score, as well as Temporal metrics (Exploitability, Remediation Level, Report Confidence), Environmental metrics (Collateral Damage Potential, Target Distribution, Impact Subscore Modifier).

CVSS V3.X severity score ranks vulnerabilities as None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9) or Critical (9.0-10.0). It includes new metrics for User Interaction, Privileges required, and Scope; Access Complexity was renamed Attack Complexity, some metrics values were updated, and Environmental metrics were replaced by a second Base score known as Modified vector.

CVSS V3.1 metrics and possible values are:

  • Base Score
    • Attack Vector (AV): Network (N), Adjacent (A), Local (L), Physical (P)
    • Attack Complexity (AC): Low (L), High (H)
    • Privileges Required (PR): None (N), Low (L), Hight (H)
    • User Interaction (UI): None (N), Required (R)
    • Scope (S): Unchanged (U), Changed (C)
    • Confidentiality (C): None (N), Low (L), High (H)
    • Integrity (I): None (N), Low (L), High (H)
    • Availability (A): None (N), Low (L), High (H)
  • Temporal score
    • Exploit Code Maturity (E): Not Defined (X), Unproven (U), Proof-of-Concept (P), Functional (F), High (H)
    • Remediation Level (RL): Not Defined (X), Official Fix (O), Temporary Fix (T), Workaround (W), Unavailable (U)
    • Report Confidence (RC): Not Defined (X), Unknown (U), Reasonable (R), Confirmed (C)
  • Environmental Score
    • Confidentiality Requirement (CR): Not Defined (X), Low (L), Medium (M), High (H)
    • Integrity Requirement (IR): Not Defined (X), Low (L), Medium (M), High (H)
    • Availability Requirement (AR): Not Defined (X), Low (L), Medium (M), High (H)
    • Modified Attack Vector (MAV): Not Defined (X), Network (N), Adjacent Network (A), Local (L), Physical (P)
    • Modified Attack Complexity (MAC): Not Defined (X), Low (L), High (H)
    • Modified Privileges Required (MPR): Not Defined (X), None, Low (L), High (H)
    • Modified User Interaction (MUI): Not Defined (X), None (N), Required (R)
    • Modified Scope (MS): Not Defined (X), Unchanged (U), Changed (C)
    • Modified Confidentiality (MC): Not Defined (X), None (N), Low (L), High (H)
    • Modified Integrity (MI): Not Defined (X), None (N), Low (L), High (H)
    • Modified Availability (MA): Not Defined (X), None (N), Low (L), High (H)

The metrics and values can be shown in a vector representation, that requires all metrics from the base score, and optionally some from the temporal or environmental score. The Severity is a combined score calculated with pre-established formula in the range from 0 to 10.

For example, for CVE-2020-0796:

  • CVSS 3.X Severity: 10.0
  • Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Pretty scary that one, isn’t it?

CVSS metrics is a complex topic that requires further study if you want to learn the fine details about this information, where you can find several websites that assist in its calculation.

Two kinds of vulnerabilities

Other experts (and me) say that there are only two kinds of vulnerabilities: those that you are going to fix, and those that you are not.

A vulnerability scanner may show you in a container or host a plethora of found vulnerabilities on operating system or software packages. You usually should focus on:

  • Those that have a fix available
  • Those that have a critical or high score
  • Those that have a known exploit

If there is a fix available, the decision is easy, go apply the fixing version. Be careful, sometimes when upgrading a component you may end up with more vulnerabilities than the one you were replacing. You may have the choice of upgrading the minor or the major version. An alternative could be to look for an equivalent piece of software or package that could replace the original one (that may be costly as it may require further modifications). In any case, integration and quality tests should be conducted prior to deploying to production to ensure the change works as expected.

Vulnerabilities with critical or high scores mean that they live on an important part of that software, or that if they are compromised the level of access a malicious actor can obtain is huge. But if there is no known exploit, it may be just something programmers have found not being done well in its code, but for which there is no practical way of exploiting. Several vulnerabilities like this, with critical score, are old but have no fix because it’s practically impossible to exploit.

An important additional consideration is risk: how critical is the workload you are protecting in the whole scheme of your application/infrastructure. For you, workloads exposed to the public Internet, that handle payments or sensitive private personal information, for example, should boost the priority of the vulnerabilities found there.

Judging what to do in each situation is part of the security specialist’s job.

SCAP and OVAL

The Security Content Automation Protocol (SCAP) is a multi-purpose framework of specifications maintained by NIST that supports automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement.

The Open Vulnerability and Assessment Language (OVAL) is one of the standards defined in SCAP, designed to check for the presence of vulnerabilities and configuration issues on computer systems. OVAL includes a language to encode system details and an assortment of content repositories held throughout the community. The official OVAL repository is hosted by the Center for Internet Security (CIS), but there are also other repositories like the ones provided by Debian, or Red Hat.

The OpenSCAP project is a collection of open source tools for implementing and enforcing this SCAP and OVAL.

For example, Red Hat’s Atomic Scan is a container vulnerability scan tool by Red Hat that forms part of OpenSCAP, and can be used to search for vulnerabilities and check compliance defined as defined by SCAP.

Is this all?

No, there are several more things you can learn from beyond CVE and NVD.

Vulnerability scanners can use alternative sources of information in addition to the CVE/NVD, like the private, subscription-based VulnDB, or Google’s Open Source Vulnerabilities (OSV) database. Here you can find a list of other vulnerability databases from mayor vendors, some in OVAL format, as well as their own CVE trackers. Some other security vendors provide their own vulnerability databases, but usually it’s just a copy of the official NVD with better UI (just look for the CVE number on each entry).

Other interesting sources of adversarial information are the Malware Attribute Enumeration and Characterization (MAEC) and the Common Attack Pattern Enumeration and Classification (CAPEC), both also by MITRE.

Conclusion

The Common Vulnerability and Exposures (CVE) by MITRE is a way to centralize the identification of vulnerabilities as they are discovered by several organizations. You should check the National Vulnerability Database (NVD) as it always improves on the base CVE, with additional information like the CVSS vulnerabilities metrics and severity. When using a vulnerability scanner, focus on critical and high vulnerabilities, that have a fix or a known exploit.

If there is some information I missed in this article, or you just want to chat with me, let me know.

And if you found this information extremely useful to you, why not let others know? Share it in a tweet, or invite me to coffee!

Vicente Herrera is a software engineer working on cloud native cybersecurity (cloud, containers, Kubernetes).
His latest job is cybersecurity specialist at Control Plane, and previously was Product Manager at Sysdig.
He is the published author of Building Intelligent Cloud Application (O’Reilly, 2019) about using serverless and machine learning services with Azure.
He has been involved in several research projects for using AI on healthcare and automatic code generation.

Security
CVE CNA MITRE NVD NIST CVSS SCAP OpenSCAP OVAL security cybersecurity cloud-native
This post is licensed under CC BY 4.0 by the author.
Recent Update
Contents

Introduction to MITRE ATT&CK

Log4j 2 vulnerabilities, part I: History