How useful are CVE entries?

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.

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.

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.

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.

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.