28

Most of the CVE entries are not supplemented by complete explanation of the bug itself, even a proof-of-concept demonstrating the bug. All they have is some very high-level, abstract description of possible side effect, e.g. CVE-2016-8412 states,

An elevation of privilege vulnerability in the Qualcomm camera could enable a local malicious application to execute arbitrary code within the context of the kernel. This issue is rated as High because it first requires compromising a privileged process. Product: Android. Versions: Kernel-3.10, Kernel-3.18. Android ID: A-31225246. References: QC-CR#1071891.

The description is devoid of any useful information, e.g. the vulnerable block of source (because it's Android), relevant analysis, possible patch (optional) etc. Are these sort of CVEs useful at all from the perspective of security research? Do they serve any real purpose apart from possibly being an index of how buggy a software is?

Improve this question
6
  • 11
    You seem disappointed that other security researchers don't give the whole internet exploits on a platter. My guess is you should be happy this is so, because you might've been personally inconvenienced otherwise. Also, diffs are gold ;)
    – J.A.K.
    Feb 9, 2017 at 20:54
  • @J.A.K. Not disappointed at all. A patched CVE (which all public CVEs are) is of no use other than research purpose
    – sherlock
    Feb 9, 2017 at 20:58
  • 3
    What about ATMs still running XP?
    – J.A.K.
    Feb 9, 2017 at 21:08
  • It's not just Windows XP. There's loads of systems and services left upatched, it's sad but it is so.
    – SaAtomic
    Feb 10, 2017 at 12:10
  • 2
    They’re mostly not very useful. They often show up as just “reserved” on most sites (including NIST and MITRE), they lack links to specific patches/commits fixing the problem, and are in general only relevant if a certain “vendor” (or distro) adds their own information themselves, but most definitely overall not helpful to distros (especially smaller ones) or others to figure out whether they are affected, what to backport, etc.
    – mirabilos
    Feb 10, 2017 at 17:17

6 Answers 6

Reset to default
43

They're useful, they're just not useful for building exploits. They're not useful for determining how buggy a software is for that matter either...The number of CVEs has no strong correlation with code quality.

What they are useful for, is determining, as an administrator, if the versions of a given software package you're using has been patched for specific known exploits, and the potential impacts of exploits that have been discovered. In this way, they can feed directly into a vulnerability management process as one of the many tools that you can use to ensure that your organization is properly managing software security risk.

Improve this answer
22

The main use case for CVE is to have unique identifiers for software vulnerabilities. It is not a good tool to measure a product's overall security and won't help you with the in-depth analysis of a bug.

You should think of CVE as a dictionary rather than a database that assigns standard names to vulnerabilities so that you can unambiguously refer to them across different systems. Don't make the mistake of assuming that a CVE entry gives you a full explanation of a vulnerability or an accurate estimation of the impact.

The About CVE page makes it pretty clear that the focus is on standardization:

CVE is:

  • One name for one vulnerability or exposure
  • One standardized description for each vulnerability or exposure
  • A dictionary rather than a database
  • How disparate databases and tools can "speak" the same language
  • The way to interoperability and better security coverage
  • A basis for evaluation among tools and databases

[...]

So CVE is not meant to be a comprehensive database of all known vulnerabilities in any product as the entries are neither verified by a third party nor necessarily complete. It's mostly useful as an overview and for having a unique identifier you can use to address the bug in a patch or a write-up.

Improve this answer
2
  • 2
    This is a great answer. In addition to providing a common vocabulary for humans to use when discussing vulnerabilities, CVE also has the goal of providing precise identifiers for machines to use when exchanging vulnerability information. In fact, it's part of a much larger program called Security Content Automation Protocol that has, unfortunately, been largely overlooked by the private sector security community.
    – Mark E. Haase
    Feb 10, 2017 at 14:43
  • its worth mentioning that CVE has direct correlation with CVSS and CWE that show the criticality of the vulnerability and a standardised description of the weaknesses themselves. This can be used for other purposes and can be used to assess the acceptability of software based on the viewers appetite for risk.
    – Callum Wilson
    Mar 6, 2017 at 14:34
13

CVEs are useful in several ways.

First, and perhaps most importantly, they provide a common term for a particular vulnerability. This makes it easy to ensure that when someone says "did you see that Android vulnerability", you're talking about the same Android vulnerability. It also vastly simplifies searching for more information on the issue.

Secondly, when you click through to NIST's page on the vulnerability, it has CVSS information that, if you're familiar with reading the notation, makes it easy to get a quick overview of how critical it is for you to patch the vulnerability in your environment.

Improve this answer
2

For me, CVEs are a bit like dictionary terms. It's meant to be able to easily communicate what something is via a common enumeration.

You can read more about why they are written that way at https://cve.mitre.org/about/faqs.html#b4

A good CVE is this one relating to OpenSSL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6304

The description is short but the page links out to relevant references which further expands upon the CVE.

In the CVE that you are using as an example there is a link out to Android security bulletin which hosts more information and Security Focus (though it doesn't mention much). If there was an exploit available then it's probaby not shared.

Improve this answer
1

As already said, they're useful... it just depends what you want to do. If you're doing security audit, which is how I'll approach my answer, having somewhere to start is important. Running something like Nessus or OpenVAS will tell you that a particular CVE correlates with a host. From there, you'll need to research if there are any exploits that are available for it using something like exploit-db.com. Exploits aren't always listed with the CVE, so due diligence is needed.

Improve this answer
0

CVEs are useful for all actors in the software chain (developers, sysadmins, customers...) to decide whether or not to take action on existing software. Proof of concepts are deliberately redacted because, as I am going to show, it takes a long time to patch the actual installations.

In a theoretical world, patches are deployed immediately to all devices. This guarantees that all devices are patched and protected. This is impossible.

Pick Android...

  • T0: A vulnerability in the Linux kernel, affecting the Android kernel, is found and patched
  • T1: Google patches AOSP and releases the patch
  • T2: mobile manufacturers (e.g. LG, Motorola, Samsung) receive the patch and apply it to their customized build
  • T3: the patch is OTA-delivered to consumers
  • T4: a company with 1000s of Android business devices from same manufacturer deploys the update to the work devices

Pick Apache...

This is similar to a case happened to me during my work

  • T0: a vulnerability in Apache is found and patched, Apache is released
  • T1: a large corporate using Apache for a lot of applications installed internall on a variety of servers schedules the upgrade
  • T2 to T100: all Apache instances are upgraded on the corporate systems, involving suppliers and managers to meet and schedule a test plan

In short

CVEs are useful to determine "how old" and "how risky" a software is. By examining the severity and the affected components the IT staff may decide whether to, e.g., not to upgrade for now, upgrade immediately, apply additional temporary security measures (e.g. firewalling, proxying).

In the corporate world there is an intrinsic slowness in software upgrade. I see banks running Java <= 1.5 (again, no later than 1.5) because later versions have not been certified and Java 1.7 is already end of life. We know companies still run XP because they don't know if all of their existing software base runs on Windows 7, not even dare try 10.

A severe CVE, according to my experience, can be the reason to prioritize a software upgrade in a structured corporate scenario.

Improve this answer

You must log in to answer this question.

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