Vulnerabilities vs. Attack Vectors

During our daily work analysing vulnerabilities in-depth, we come across cases on a regular basis where a single vulnerability with multiple attack vectors is being reported as separate vulnerabilities. To quickly cover our definitions of the terms: A “vulnerability” is a specific problem in the code having a security impact while an “attack vector” is a way of triggering / reaching the vulnerability.

There may be a number of reasons why we see different attack vectors being reported as separate software vulnerabilities. Perhaps it’s because it may take a lot of time and skill to fully understand some vulnerabilities, making it faster and/or easier to just report something as multiple vulnerabilities without determining anything else than that there is “memory corruption”; an increasingly popular term.

As an example: Not that long ago, we did a quick test run of an internally developed fuzzer by pegging it against a product from Adobe Systems. Overnight, the fuzzer generated 400+ crash reports. Out of those crashes, about 80 of them occurred due to “memory corruption”; as half of these were triggered by manipulating different fields, this could mean that our fuzzer had found about 40 separate vulnerabilities. However, after properly analysing each crash, they all turned out to be caused by just four different vulnerabilities (having a large number of attack vectors).

As evident from the example, it may take quite a lot of time to properly understand the core problem of software vulnerabilities. In this case, it took a Senior Security Specialist, who’s an experienced vulnerability analyst and reverse engineer, almost a week to go through the interesting crashes and confirm the root causes. A less experienced person would have spent a lot longer, if ever, figuring some of the problems out.

Generally, the reasons for not fully determining the root cause of software vulnerabilities before reporting it can probably be divided into three categories:

1. The reporter simply does not want to spend the time and effort required to figure out the core problem, but leaves that part up to someone else (e.g. the software vendor).
2. The reporter lacks the skills to properly analyse and understand the root cause of the vulnerability.
3. The reporter purposefully reports each attack vector as a separate vulnerability because it looks “better” (i.e. more vulnerabilities were discovered).

Reasons #1 and #2 are, of course, perfectly fair if the reporter is a hobby researcher not doing this as a full-time job. However, whatever the reason, reporting multiple attack vectors as multiple software vulnerabilities remains a problem for both the software vendors (looks like there are more vulnerabilities in their products than is the case), vulnerability databases like Secunia and similar organisations (risk of issuing duplicate identifiers/advisories for the same vulnerability), and many other actors in the field that rely on the reported number of vulnerabilities (e.g. various organisations documenting vulnerability statistics and doing comparisons, which may be anywhere from slightly flawed to completely wrong).

Hopefully, both software vendors and researchers will do their part to ensure that vulnerabilities are being reported more accurately. At Secunia, we try to do our part by spending a large amount of resources on analysing and properly understanding both the vulnerabilities reported by third parties as well as the ones discovered internally by the Secunia Research team.