2014 CVE Analysis
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
2014 CVE analysis
2
3
This survey of CVE vulnerabilities is part of the research done for ASAP:
High System-Code Security with Low Overhead.
Jonas Wagner, Volodymyr Kuznetsov, Azqa Nadeem, George Candea, Johannes Kinder
IEEE Symposium on Security and Privacy (S&P), San Jose, CA, May 2015

Methodology:

The source of our data is the official data feed from the National Vulnerability Database (https://nvd.nist.gov/download.cfm). There are a total of 7143 entries for the year 2014.

We first selected vulnerabilities related to memory errors, for which instrumentation tools like AddressSanitizer are applicable. We used a combination of existing classification (entries with CWE-id 119 are memory safety issues) and keywords found in the summary (e.g., "memory corruption", "buffer overflow", or "out-of-bounds access"). Where the two criteria gave different results, we relied on manual inspection of the summary. We found 875 memory-safety vulnerabilities.

In a next step, we obtained links to the patches that fixed the vulnerabilities. We obtained such links from references in the CVE entry. In many cases, we were not able to access a patch, for example because the software is closed-source, does not have a public version-control system, or does not disclose vulnerability details. There were 180 memory-safety vulnerabilities with patch.

In the final step of the analysis, we examined the patch and the surrounding source code to determine whether the vulnerability lies in hot (i.e., performance-critical and frequently executed code) or in cold code. We used four criteria (described below) that indicate that a given piece of code is cold. In the absence of any of these, we classified the code as potentially hot. We found that at least 83% of the analyzed vulnerabilities lie in cold code.
4
5
CriterionExplanation
6
Absence of loops and recursionWe classify a code region that does not lie inside a loop or recursively called function as cold, because it is unlikely to be executed multiple times.
We also use this classification for bugs that involve very small buffers (<255 elements) because loops that process them do not have a high iteration count.
7
Initialization codeWe classify vulnerabilities inside the main() function, constructors or destructors for global objects, and code to initialize/cleanup complex operations as cold, because it will be executed only once or a few times.
8
Comments and external informationFor some parts of a program, comments from the program developers or external information indicates that the code is rarely used. For example, it may be related to a rarely-used optional feature, an exotic file format, or marked as obsolete or deprecated.
9
Long code pathSome vulnerabilities are part of a long code path, for which the total runtime is dominated by code before/after the vulnerability. In this case, the vulnerable code contributes little to the total program runtime, and it is unlikely to be hot.
10
11
Results
12
Total CVEs7143
13
CVEs related to memory errors879
14
... and with a public patch180
15
16
CVEs classified as hot24=16.55%
of known classified vulnerabilities
17
CVEs classified as cold121=83.45%
of known classified vulnerabilities
18
CVEs classified as unknown35
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Loading...
 
 
 
Introduction
CVEs