What is a Vulnerability?

In discussions and meetings with other information security professionals, I hear a lot of misinformation. I’m a geek and like to be more precise, rather than less.  The use of the term vulnerability is a special pet-peeve of mine.  The core of information assurance is making sure you don’t have serious vulnerabilities. So, what exactly is a vulnerability?  Let’s get it straight.

I sort of like the definition offered by Mitre and their Common Vulnerabilities and Exposures: An information security “vulnerability” is a mistake in software that can be directly used by a hacker to gain access to a system or network.  This means that a vulnerability is a means of illicit access.  And through this access, an evil person could violate confidentiality, integrity or availability.

It’s like saying I was robbed by an unlocked door.

A vulnerability does not define an illicit action, like stealing passwords, destroying files or modifying data.  Rather, it focuses on a flaw that may allow access. An exploit is a tool or technique that takes advantage of a vulnerability.  It gains access and does the damage.  If you leave your front door unlocked, you are vulnerable to stuff being stolen.  Unlocked door = vulnerability. Robber = Exploit. Thus, my inner geek rails when I hear someone say “We were hit by the XYZ vulnerability.” No, you were hit by an exploit.    It’s like saying I was robbed by an unlocked door.

One more little thing.  That site was Common Vulnerabilities and Exposures.  An exposure involves allowing access to information that could be used to discover vulnerabilities. Mitre defines an exposure as “An information security “exposure” is a system configuration issue or a mistake in software that allows access to information or capabilities that can be used by a hacker as a stepping-stone into a system or network.” An example of this would be grabbing the header from a Web server.

HTTP Header captured from Wireshark
HTTP Header captured from Wireshark, showing the server and version.

The information above was gained using Wireshark to capture a browser connecting to a Web site.  We see that the server was running Microsoft IIS, version 6.0.  If you are an attacker, this would be good preliminary information. However, it is not momentous enough to allow the Russian mafia in to pillage and plunder. Yet, it is useful reconnaissance.

It would be good to rid your self of exposures, but it may not be possible. Many exposures are not fixable. If you are running a Web server for the public, it is not really possible to hide that fact.

Vulnerability Names

The greatest thing about CVE is the standardized name.  Years ago, before CVE came into being in 1999, vulnerabilities had arbitrary names. Every researcher and security company that discovered a vulnerability made up a name for it. Thus, one vulnerability scanner might call its discovery the “Windows NETAPI buffer overlow”. Another scanner could call the same issue the “SMB Remote Code Execution Technique”.  Both might refer to the same thing.  But you wouldn’t immediately know if your scanners had discovered one vulnerability with two names, or two unique vulnerabilities.

It’s like a Social Security Number for vulnerabilities.

CVE solves this problem.  This database is a central registry for vulnerability naming and information. It’s like a Social Security Number for vulnerabilities.  Let’s look at an entry in CVE. Below, we see an entry in their database for an Adobe Flash Player issue.

CVE-2012-0779 from the CVE database at Mitre

This identifies a specific flaw in Adobe Flash Player. The entry assigns an ID: CVE-2012-0779.  They all have a prefix of CVE. The 2012 means the issue was reported in the year 2012.  The problem could date back years.  The value 0779 is roughly a serial number. The serial number is not purely incremental. So, this is not the 779th vulnerability of the year.  The truth is that major software vendors have whole blocks of numbers pre-assigned. Microsoft gets a block of numbers, as do Adobe, Oracle and others.

Next, we have the description.  This generally provides detailed information on which versions of the software are vulnerable and an overview of the flaw. Notice that the version information is quite detailed. It tells also you a bit about the potential impact, should someone take advantage of the vulnerability. With the version information, you could go into Flash Player, choose Help > About, and determine for yourself whether you were vulnerable.

CVE does not directly publish exploit information.  Remember, an exploit is something else entirely.  Mitre’s goal is to publish the information necessary to identify flaws, not teach us how to perform exploits.  Interestingly, you will often find links to sites that have exploit information. So, there is a little wiggle room in that no exploits rule.

Be careful.  CVE has mistakes.

CVE is a great resource, but it is not perfect.  The whole world regards CVE as the fountainhead of vulnerability knowledge.   But, here is a shocking statement: not everything you read on the Internet is true. Be careful.  CVE has mistakes. The mistakes are few, but you should know CVE is imperfect. The most common type of mistake is the vulnerable version numbers. I’ve seen plenty of cases where CVE has mixed up the difference between less than and less than or equal to. For example, CVE might say that a vulnerability affects the XYZ application, versions less than 1.2.3.  But, in reality, vulnerable version include 1.2.3.  It’s always good to verify information with other sources.

Other Vulnerability Databases

Mitre does not have a monopoly on identifiers and vulnerability information. You can cross-check information and learn more with other resources.

  • Securityfocus.com.  This site is owned by Symantec, but it is fair and thorough. They often post information about vulnerabilities before CVE. SecurityFocus assigns an identifier as one digit, called a Bugtraq ID (BID). It has excellent version information and references to solutions/remediation. In contrast to CVE, this site will post exploit information.
  • OSVDB. The Open Source Vulnerability Database is a community-run effort that was founded in 2002. It posts exploit information, as well as detailed references.  It, too uses a single number to identify each entry. You may review an example here.
  • Vendor advisories.  There are hundreds of these. It is up to each vendor to determine what information to publish and when to do so.  Often these advisories have the most accurate version information. It’s their product – they should know.  On the down side, they often trivialize or play down the severity of an issue.
  • NVD. The National Vulnerability Database is an extension of CVE that is run by the National Institute of Standards and Technology (NIST).  When an entry is introduced to CVE, it is added to NVD.  In addition, it has excellent version information, and a rating system , called Common Vulnerability Scoring System to measure vulnerability severity.

All of these cross-reference their IDs and bulletins with CVE-IDs.

Whether you work at a Help Desk, vulnerability assessment or are a pen tester, this is all key information. Knowing if your systems are at risk is important.  It starts with understanding and using the right terms.  While mixing up the terms vulnerabilities and exploits happens, it’s best to be accurate. Even referring to a vulnerability has its issues.  CVE is the universal name.  CVE entries can tell give you a name, description and severity information.  This helps you decide how much risk you face. But, it’s not the sole panacea of truth.  It has mistakes.  Fortunately, there are plenty of other resources.

If you are interested in vulnerability scanning and assessment, the course Vulnerability Assessment includes this topic.

Randy W. Williams

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.