Professional Documents
Culture Documents
How Vulnerabilities Are Exploited: The Root Causes of Exploited Remote Code Execution Cves
How Vulnerabilities Are Exploited: The Root Causes of Exploited Remote Code Execution Cves
Manual code reviews performed by developers and testers, in concert with automated tools
such as fuzzers and static analysis tools, are very helpful techniques for identifying
vulnerabilities in code. But these techniques cannot find every vulnerability in large scale
software projects. As developers build more functionality into their software, their code
becomes more and more complex. The challenge of finding vulnerabilities in very complex
code is compounded by the fact that there are an infinite number of ways that developers
can make coding errors that can create vulnerabilities, some of which are very, very subtle.
Have you ever wondered what a vulnerability looks like? To illustrate how subtle a security
vulnerability can be, the following small code sample contains a vulnerability that is difficult
to find using code reviews or tools or both.
Can you spot the problem(s) in Figure 1? The developer who wrote this code intended to
have the code check whether the user running the program should be denied access to the
program or if they should be granted access. The problem in this code is that the function
(AccessCheck()) that the developer is using to decide whether to grant access to the user,
can fail for many reasons, many of which are not conditions related to denying access. For
example, if the application runs out of memory for any reason during this operation, the
function could return an “out of memory” error instead of the “access denied” error that the
developer was expecting. Because the developer only checks for an “access denied” error,
this code will grant access to the user if any error other than “access denied” error is
returned. This is, therefore, a vulnerability that could potentially be exploited if an attacker
could create the right conditions.
Trustworthy Computing’s Security Science team studied the root causes of the most severe
vulnerabilities in Microsoft software, those that enable remote code execution (RCE), and
were known to be exploited between 2006 and 2013. The root cause of a vulnerability plays
a key role in defining the set of exploitation techniques that an attacker can use when
developing an exploit. As a result, the level of difficulty in developing an exploit is heavily
1/3
dependent on the type of vulnerability that is being exploited. In terms of risk management,
the root cause of a vulnerability can be an important factor in influencing the likelihood that
an exploit will be developed. As Figure 2 illustrates, there have been some noteworthy
shifts in the classes of vulnerabilities that are known to have been exploited.
Figure 2: The root causes of exploited Microsoft remote code execution CVEs, by
year of security bulletin, as published in the Microsoft Security Intelligence Report
volume 16
A clear shift can be seen in the declining percentage of exploits for stack corruption
vulnerabilities, such as stack-based buffer overflows, which accounted for 54.2 percent of
known exploited Microsoft remote code execution CVEs in 2007 but accounted for just 5.0
percent in 2013. This decline isn’t accidental. In 2006 Microsoft deprecated a subset of the
C runtime library to remove functions that were known to present security threats, with a
focus on buffer overruns. At first this requirement was simply articulated in the form of a list
of bad APIs, but it changed over time to become a header file (Banned.h) that could be
used in conjunction with a compiler to help provide an automated method of sanitizing
source code. This became a requirement in the Microsoft Security Development Lifecycle,
which developers at Microsoft use to develop software.
This vulnerability class has historically been the most likely to be exploited, but has declined
considerably since its 2007 peak. Two other factors that could also be contributing to this
decline are the increasing prevalence of exploit mitigations for stack corruption issues
(such as /GS and SafeSEH) and the increasing effectiveness of static analysis tools
designed to detect such vulnerabilities.
The introduction of technologies such as Data Execution Prevention (DEP) and Address
Space Layout Randomization (ASLR) has also affected the way attackers attempt to exploit
vulnerabilities. Figure 3 shows the techniques used in exploits targeting vulnerabilities in
Microsoft products that were discovered over the past two years.
This data suggests that the increasing prevalence of DEP and ASLR has forced attackers
to identify new techniques that can be used to exploit vulnerabilities even when ASLR and
DEP are enabled. An increasing number of exploits attempt to bypass ASLR by relying on
images that have not opted into ASLR or by taking advantage of a vulnerability to disclose
information about the layout of an application’s address space.
Requiring attackers to bypass DEP and ASLR makes developing exploits more difficult and
expensive, which has likely been a major factor in the 70 percent reduction in the number
of remote code execution vulnerabilities that were exploited in Microsoft software over the
past three years. Increased adoption of recent versions of Internet Explorer and EMET
could help contribute to this positive trend, as developing effective exploits becomes even
more difficult.
Tim Rains
Director
Trustworthy Computing
3/3