Software Vulnerability Exploitation Trends. Exploring the impact of software mitigations on patterns of vulnerability exploitation

Transcription

1 Software Vulnerability Exploitation Trends Exploring the impact of software mitigations on patterns of vulnerability exploitation

2 Software Vulnerability Exploitation Trends This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Copyright 2013 Microsoft Corporation. All rights reserved. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Authors Swamy Shivaganga Nagaraju Microsoft Security Response Center Cristian Craioveanu Microsoft Security Response Center Elia Florio Microsoft Security Response Center Matt Miller Microsoft Security Engineering Center 1 Vulnerability Exploitation Trends

3 Table of contents Foreword... 3 Introduction... 4 Exploitation trends... 5 Improvements in Windows Recommendations References Appendix: Data Sources and Glossary Vulnerability Exploitation Trends 2

4 Foreword Using security science to create more secure products and services The Microsoft Security Engineering Center carries out some of the software industry s most advanced security science research. Leveraging insights we glean from the Microsoft Security Response Center, the team examines new techniques that are used to attack Microsoft products and services and third-party applications running on Microsoft platforms. They use this understanding on how the attacks succeed to design countermeasures to defeat them. The output of this research feeds back into the Microsoft Security Development Lifecycle, a mandatory part of the development process that every Microsoft product or service must implement. The result is that each new version of an operating system, browser or application is harder to attack than previous versions, making it more difficult and costly for criminals to develop malicious attacks. The more expensive it is to develop an attack, the less likely it is that the attack will be created and used. This whitepaper examines the effectiveness of this approach. The paper analyzes software vulnerabilities addressed through Microsoft security updates that were exploited, and provides recommendations that can help to minimize risk of attack. Two findings are clear first, the innovations introduced by security science have forced attackers to change the attack methods they use, often requiring the development of more expensive multi-stage attacks. Second, new attacks continue to be developed for older, less secure versions of products and services. A special note to those still running Windows XP - the paper also examines the security features in Windows XP Service Pack 3 and compares them with the features in Windows 8, our most secure operating system to date. Only a quarter of Windows 8 protections are available in any form in Windows XP Service Pack 3. This means that the attack techniques that have been developed in the ensuing eight years can still be deployed against Windows XP, even though those techniques are mitigated by the updated security features in Windows 8. Running Windows XP on network-connected systems carries additional risk; the fact that Windows XP will no longer be supported at all after April 8, 2014 means that this risk will only increase over time. The Microsoft Security Engineering Center continues their work examining new attack techniques as they are developed, which will ensure the security of Microsoft products and services keeps pace with ever-improving attack techniques. Matt Thomlinson General Manager Microsoft Trustworthy Computing Security 3 Vulnerability Exploitation Trends

5 Introduction One of the security challenges that both individuals and organizations face is gauging the risks that are associated with vulnerabilities in the operating systems and applications that they use. Although such vulnerabilities always have some level of potential risk, this risk only becomes actualized when an attacker develops a functioning exploit. The existence of an exploit is what allows a malicious attacker to take advantage of a vulnerability and potentially compromise affected computers. From a risk management perspective, the likelihood of an exploit being developed can be an important factor in providing a more precise estimation of a vulnerability s actual risk. To this point, Microsoft security updates always include a description of a vulnerability s expected worst-case impact and, beginning in 2008, an Exploitability Index 1 (XI) rating that measures the likelihood of a vulnerability actually being exploited. This white paper explores the impact of improvements that Microsoft has made over time to address software vulnerabilities. This analysis is based on a survey of Microsoft vulnerabilities that have been addressed through security updates over the past seven years ( ) and are known to have been exploited. The survey focuses on assessing trends in the types of vulnerabilities that have been exploited, the product versions that have been targeted, and the exploitation techniques that have been used by attackers. It also highlights security improvements in Windows 8 that help mitigate techniques that are currently being used by attackers. The findings of this survey were used to create a set of recommendations on how to effectively minimize risk associated with software vulnerabilities. A key factor that influences the likelihood that a vulnerability will be exploited is how difficult and costly it will be for an attacker to develop a reliable exploit. Over the past decade, Microsoft has introduced numerous defense-in-depth security features into Windows and other products that have been specifically designed to increase the cost and complexity of developing exploits. These security features, which are detailed in the white paper Mitigating Software Vulnerabilities, 2 are particularly noteworthy because they offer protection even when the details of a vulnerability are not yet known to a vendor or a vulnerability has not yet been addressed through a security update. A KEY FACTOR THAT INFLUENCES THE LIKELIHOOD THAT A VULNERABILITY WILL BE EXPLOITED IS HOW DIFFICULT AND COSTLY IT WILL BE FOR AN ATTACKER TO DEVELOP A RELIABLE EXPLOIT Vulnerability Exploitation Trends 4

6 Exploitation trends This section explores historical exploitation trends for Microsoft vulnerabilities that have been addressed through security updates within the past seven years ( ). Evidence about which vulnerabilities have been exploited was gathered from public and private reports as well as Microsoft antimalware telemetry feeds. Although this data is believed to be thorough and complete, it is possible that vulnerabilities may have been exploited without being detected. However, the scale of any such exploitation is expected to have been small because no discernible evidence exists. Unless otherwise stated, this analysis focuses on remote code execution (RCE) vulnerabilities because these vulnerabilities are often the most severe. KEY FINDINGS The key findings that were made through this analysis of historical exploitation trends are: The number of RCE vulnerabilities that are known to be exploited per year appears to be decreasing. Vulnerabilities are most often exploited only after a security update is available, although recent years have shown an upward trend in the percentage of vulnerabilities that are exploited before a security update is available. Windows 7 and Internet Explorer 9 are being increasingly targeted by exploits. Stack corruption vulnerabilities were historically the most commonly exploited vulnerability class, but now they are rarely exploited. Use after free vulnerabilities are currently the most commonly exploited vulnerability class. Exploits increasingly rely on techniques that can be used to bypass the Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR). 5 Vulnerability Exploitation Trends

7 Scale To help set the context for assessing exploitation trends, it is helpful to start by considering the scale at which vulnerabilities are actually known to have been exploited. The following figure represents the number of common vulnerabilities and exposures (CVEs) that were classified as RCE CVEs over the last seven years. This data shows that approximately 29% of the CVEs addressed during this period had evidence of being exploited, ranging from 18% in 2008 to 41% in The data also suggests that 2011 was a turning point in the upward trend of vulnerabilities being exploited and that 2012 showed a significant decline in the number of known exploits. As subsequent sections will show, this decline coincides with the increasing adoption of Windows 7, Office 2010, and Internet Explorer 9 all of which benefit from stronger defenses. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Known exploit No known exploit Figure 1. CVEs that were exploited and resolved through security updates The general timeframe within which vulnerabilities are known to be exploited is also an important factor when managing risk. The following figure shows that, with the exception of 2006 and 2007, most RCE issues only had evidence of being exploited after a security update was available. This information emphasizes the point that staying current with security updates is an effective way to minimize risk. However, recent years have shown an upward trend in the percentage of vulnerabilities that are exploited before a security update is available. This increase means that it is also important to have mitigations in place that are able to complicate exploitation without requiring prior knowledge of a specific vulnerability. Vulnerability Exploitation Trends 6

8 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Exploited before update Exploited after update The Windows Vista lull Figure 2. Percentages of CVEs that were exploited before vs. after security updates were available In 2007 and 2008, there was an apparent lull in the number of CVEs that were known to have been exploited. This lull occurred despite the fact that the total number of RCE vulnerabilities that were addressed through security updates actually increased compared to One explanation for this lull is that the release of Windows Vista may have forced a period of attacker innovation, because Windows Vista included many security improvements that were designed to break exploitation techniques that attackers relied on at the time. Most notably, Windows Vista was the first version of Windows to support address space layout randomization (ASLR) as well as a significantly hardened heap implementation. Targets The product versions that are affected by a vulnerability are what define the set of at-risk targets that an attacker could attempt to exploit. In practice, exploits often target only a small subset of the affected product versions, for multiple reasons; one key factor is that the runtime environment of an application tends to be different between product versions. These differences can make it difficult to build an exploit that functions and is reliable against the complete set of potential targets. Accordingly, exploit writers typically target affected versions that are seen as high yield, such as those versions that are used by the largest portions of the population. Of the exploit data that was analyzed, only 34% of the CVEs had at least one exploit for which the intended targets were known. The following figure shows the versions of Windows that were targeted for this subset. Notably, a downward trend is evident over the last seven years in the number of exploits that targeted Windows 2000, which no longer appeared as a target in The number of exploits that targeted Windows XP and Windows Vista has also begun trending downward in the past three years, which corresponds to the increase in exploits that target Windows 7. 7 Vulnerability Exploitation Trends

9 CVEs CVEs Windows Windows XP Windows Vista Windows Figure 3. The number of CVEs for which exploits were written that targeted specific Windows versions For exploits that targeted vulnerabilities reachable through Internet Explorer, the following figure shows how Internet Explorer 6, 7, and 8 appear to be trending downward as targets whereas Internet Explorer 9 started being explicitly targeted in As a point of reference, the release dates for each version of Internet Explorer were as follows: Internet Explorer 6. August, 2001 Internet Explorer 7. October, 2006 Internet Explorer 8. March, Internet Explorer 9. March, Internet Explorer Internet Explorer Internet Explorer Internet Explorer Figure 4. The number of CVEs for which exploits were written that targeted specific Internet Explorer versions Vulnerability Exploitation Trends 8

10 Vulnerabilities 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 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 the following two figures illustrate, there have been some noteworthy shifts in the classes of vulnerabilities that are known to have been exploited. The first clear shift can be seen through the decline in the percentage of exploits for stack corruption vulnerabilities, such as stack-based buffer overruns. (See the Glossary section at the end of this paper for a definition of stack corruption vulnerabilities.) This vulnerability class has historically been the most likely to be exploited, but since 2009 it has been steadily declining. Two factors that could 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. A second shift can be seen in the increasing number of use after free vulnerabilities that have been exploited. This vulnerability class includes issues that arise because of incorrect management of object lifetimes (see the Glossary section at the end of this paper for a definition of use after free vulnerabilities.) One reason for this increase is that client-side vulnerabilities have become a prime focus for attackers and object lifetime issues are a common vulnerability class encountered in applications such as web browsers. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Stack Corruption Heap Corruption Use After Free Type Confusion Command Execution Unsafe DLL Load Uninitialized Use Invalid Free Memory Read Other XSS Cryptography Unsafe Control Transfer Figure 5. The distribution of CVE vulnerability classes for CVEs that are known to have been exploited 9 Vulnerability Exploitation Trends

11 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Windows 2000 Windows XP Windows Vista Windows 7 Stack Corruption Use After Free Heap Corruption Command Execution Type Confusion XSS Unsafe DLL Load Uninitialized Use Invalid Free Other Unsafe Control Transfer Figure 6. The distribution of CVE vulnerability classes for which exploits were written that targeted specific versions of Windows over the past seven years Techniques Attackers have developed a variety of exploitation techniques over time that can potentially enable them to exploit vulnerabilities under differing circumstances. These techniques encompass the fundamental methods of leveraging a particular class of vulnerability as a means of running malicious code. In recent years, additional techniques have been identified for bypassing exploit mitigations such as DEP and ASLR under certain conditions. From a risk management perspective, the ability for an attacker to employ certain exploitation techniques can be another factor that influences the likelihood that an exploit will be developed for a vulnerability. Of the exploit data that was analyzed, approximately 28% of the CVEs had an exploit for which the exploitation techniques were readily identifiable. The different exploitation techniques that were used by these exploits is shown in the following figure. Vulnerability Exploitation Trends 10

12 CVEs Bypass ASLR (info disclosure) Bypass DEP (.NET control) Heap Spray Stack SEH Overwrite Bypass ASLR (non-aslr image) Bypass DEP (ROP) Stack Return Address Overwrite Figure 7. The number of CVEs that were exploited using specific exploitation techniques As this data suggests, the increasing prevalence of DEP and ASLR has forced attackers to identify techniques that can be used to exploit vulnerabilities even when these features are enabled. These techniques have led to an increasing number of exploits that attempt to bypass ASLR by relying on images that have not opted into ASLR or by leveraging a vulnerability to disclose information about the layout of an application s address space. Similarly, the use of return-oriented programming (ROP) has become common in exploits that seek to bypass DEP. The increasing use of ROP was a focal problem for the winning solutions that were submitted to the Microsoft BlueHat Prize competition in 2012 some of which were integrated into the Microsoft Enhanced Mitigation Experience Toolkit (EMET) 3.5 technical preview. The data in the preceding figure also shows that attackers leveraged.net user controls between 2008 and 2010 as a method of bypassing both DEP and ASLR in Internet Explorer, but this technique was mitigated with the release of Internet Explorer 8 in 2009 and therefore is no longer useful to attackers who try to exploit Internet Explorer 8 and more recent versions. The data on which classes of vulnerabilities have been exploited showed a clear downward trend in the number of stack corruption vulnerabilities that are being exploited. This trend is further reflected by the decrease in the number of exploits that rely on stack-based exploitation techniques such as return address and SEH overwrites. Would enabling certain mitigations have broken exploits seen in the past? Another way to view the techniques used by attackers is to identify exploits that would no longer function correctly if a mitigation were enabled. The chart in the following figure shows the number of CVEs that had exploits that would have been mitigated if DEP were enabled compared to the number of CVEs that had exploits that bypassed DEP. With the exception of the lull in 2007 and 2008, there appears to be a clear downward trend in DEP s ability to retroactively break exploits. This trend is not because DEP is no longer effective; rather, it is an indication that attackers have been forced to adapt to environments in which DEP is already enabled at increased cost and complexity. The evidence is the increasing number of CVEs that had exploits that bypassed DEP. 11 Vulnerability Exploitation Trends

13 CVEs Mitigated by DEP Bypassed DEP Figure 8. The number of CVEs for which exploits were written that could have been mitigated by enabling DEP as compared to the number of CVEs that had exploits that bypassed DEP Vulnerability Exploitation Trends 12

14 Improvements in Windows 8 Windows 8 contains numerous security improvements that are specifically designed to increase the cost and complexity of exploiting vulnerabilities. This section highlights some of the security improvements in Windows 8 by showing the impact they are designed to have on current trends in vulnerability exploitation. Enhanced /GS Stack corruption vulnerabilities are rarely exploited in Microsoft products today, thanks in part to the /GS stack buffer overrun protection and SafeSEH features of the Microsoft Visual C++ compiler. Despite this positive trend, there have still been cases during the past seven years in which stack corruption vulnerabilities were successfully exploited. In Visual C , the heuristics that /GS uses when deciding whether to enable protection for a function were extended to cover a broader set of cases. For example, the new heuristics now protect functions that have a plain old data structure (POD) of a certain size or that have a fixed-size local array of a non-pointer type. These enhanced heuristics provide protection for past vulnerabilities that were not previously protected by /GS. Because Windows 8 has been built with these enhancements to /GS, it will be even more difficult for attackers to develop an exploit for stack corruption vulnerabilities that may exist in Windows 8. Heap hardening Heap corruption vulnerabilities are one of the most commonly exploited vulnerability classes. In most cases, attackers attempt to exploit these vulnerabilities by corrupting the state of application data that is stored on an application s heap. For example, an attacker might use a heap buffer overrun to corrupt the virtual table of a C++ object that is later called through, which would allow them to take control of program execution. heap corruption vulnerabilities often require precise control of where objects are allocated on the heap with respect to one another. By randomizing the order in which objects are allocated, Windows 8 makes it more difficult for an attacker to reliably position objects within the heap. In addition, Windows 8 also inserts no-access guard pages between certain regions within the heap. These pages help to ensure that an application will terminate if an exploit causes a program to read or write to them. Both of these features are enabled by default in Windows 8, so all applications are able to benefit from them. VTGuard (Virtual Table Guard) Use after free vulnerabilities are currently the most exploited vulnerability class in Internet Explorer. To exploit these vulnerabilities, attackers generally rely on creating a fake instance of a C++ object that has a fake virtual function table whose content is controlled by the attacker. In this way, an attacker is able to force an application to execute attacker-specified code when a virtual method call is made. To help mitigate this, Internet Explorer 10 takes advantage of a compiler security feature known as VTGuard. This feature acts as a probabilistic mitigation for vulnerabilities that can be used to corrupt a C++ object s virtual table pointer. VTGuard works by adding a secret value as an element of the virtual table for a protected C++ class. The compiler also inserts logic prior to each virtual method call for the protected class. At runtime, this logic verifies that the virtual table for the current C++ object has the expected secret value. If the secret cannot be confirmed, the application is safely terminated. In Windows 8, new security features have been added to the heap that were specifically designed to make it more difficult to corrupt application data on the heap. Exploits that are written for 13 Vulnerability Exploitation Trends

15 Force ASLR The most common exploitation technique that is currently used to bypass ASLR involves taking advantage of a dynamic-link library (DLL) that has not actually opted into ASLR. By coercing an application into loading such a DLL, an attacker can cause known executable code to be placed at a known fixed location in the address space of an application. This placement can enable an attacker to make use of other techniques to bypass DEP. To prevent attackers from using this technique, Windows 8 introduced support for a feature known as Force ASLR. When Force ASLR is enabled for an application, all relocatable DLLs will be mapped at a randomly selected base address regardless of whether or not they have opted into ASLR. Because Internet Explorer and Office were often targeted by exploits that relied on non-aslr DLLs, Internet Explorer 10 and Office 2013 have both enabled Force ASLR as well. For versions of Windows prior to Windows 8, the Microsoft Enhanced Mitigation Experience Toolkit (EMET) can be used to enable Force ASLR. High Entropy ASLR Heap spraying has consistently been one of the most popular techniques used by exploits over the past seven years. Exploit writers generally use heap spraying to place attacker-controlled code or data at a desired location in memory. This placement is typically accomplished by coercing an application into allocating large quantities of data and thereby filling a large portion of the address space. In Windows 8, 64-bit applications that enable support for High Entropy ASLR are generically protected against traditional heapspraying techniques because High Entropy ASLR uses 24 bits of entropy when selecting the base address for heap regions. Approximately 1 terabyte of variance is available for allocation of heap regions, which means that an attacker would need to allocate more memory than a commodity PC typically has to reliably control the content of memory at a known address. Like the Force ASLR feature, the 64-bit versions of Internet Explorer 10 and Office 2013 have both enabled High Entropy ASLR. Vulnerability Exploitation Trends 14

16 Comparing Windows XP to Windows 8 The threat landscape has changed dramatically since Windows XP was first released 12 years ago. In the years that followed Windows XP s initial release, multiple internet worms were created that exploited vulnerabilities in remote services provided by Windows (Code Red, Blaster, Sasser). Microsoft responded to these attacks by releasing Windows XP Service Pack 2 in August 2004 which enabled the Windows firewall by default and also introduced support for Data Execution Prevention (DEP). These platform security features played a key role in helping to address the major threats at that time. Windows XP Service Pack 3 was released in April This is the final Service Pack for Windows XP, and will not be supported after April 8 th After that date there will be no more security updates released for any version of Windows XP. As of 2013, the predominate threats that individuals and organizations face are now much different. Rather than actively targeting remote services, attackers primarily focus on exploiting vulnerabilities in client applications such as web browsers and document readers. In addition, attackers have refined their tools and techniques over the past decade to make them more effective at exploiting vulnerabilities. As a result, the security features that are built into Windows XP are no longer sufficient to defend against modern threats. To illustrate this point, the table below compares the mitigation features supported by Internet Explorer 8 on Windows XP Service Pack 3 with the features supported by Internet Explorer 10 on Windows 8. As this table shows, Internet Explorer 10 on Windows 8 benefits from an extensive number of platform security improvements that simply are not available to Internet Explorer 8 on Windows XP. Windows XP SP3 Internet Explorer 8 Windows 8 Internet Explorer 10 SEHOP No Yes Protected Mode No Yes Enhanced Protected Mode (EPM) No Yes Virtual Table Guard No Yes ASLR Limited Extensive Stack randomization No Yes Heap randomization No Yes Image randomization No Yes Force image randomization No Yes Bottom-up randomization No Yes Top-down randomization No Yes High entropy randomization No Yes PEB/TEB randomization Yes Yes Heap hardening Limited Extensive Header encoding No Yes Terminate on corruption No Yes Guard pages No Yes Allocation randomization No Yes Safe unlinking Yes Yes Header checksums Yes Yes /GS Yes Yes Enhanced /GS No Yes SafeSEH Yes Yes 15 Vulnerability Exploitation Trends

17 Malware infection rates on different operating system versions The security features that are available with different versions of the Windows operating system and the differences in the way people and organizations use each version affect the malicious software infection rates for the different versions and service packs. The Microsoft Security Intelligence Report (SIR) shows the normalized malicious software infection rates for several different versions of Windows. This infection rate data is gathered from the Malicious Software Removal Tool (MSRT) which executes on more than 600 million Windows systems around the world each month. The data gathered is normalized to allow comparison between the various different operating system versions and service packs, and displayed as a metric called CCM (Computers Cleaned per Mille) which represents the number of computers cleaned for every 1,000 executions of the MSRT. The data in the latest version of the SIR shows a dramatic difference in malicious software infection rates between Windows XP Service Pack 3 and later versions of Windows, especially Windows Too little data 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit Windows XP SP3 Windows Vista SP Too little data Windows 7 RTM Windows 7 SP1 Windows 8 RTM Windows Server 2003 SP2 Too little data Windows Server 2008 R2 SP1 Figure 9. Infection rate (CCM) by operating system and service pack in the fourth quarter of 2012 Vulnerability Exploitation Trends 16

18 Recommendations The likelihood that a vulnerability will be successfully exploited depends on many factors, including the type of vulnerability being exploited, the product versions being targeted, an attacker s ability to make use of the necessary exploitation techniques, and the amount of time required to build a reliable exploit. The following recommendations show how these factors can be influenced to help reduce the likelihood of exploitation and thereby minimize risk. Stay current on security updates Most vulnerabilities only showed signs of being exploited after a security update had been made available. Installing security updates as soon as they are available can help minimize risk. Use the newest application versions Windows 8, Internet Explorer 10, and Office 2013 all take advantage of improved security features that more effectively mitigate techniques that are currently being used to exploit vulnerabilities. Use the Enhanced Mitigation Experience Toolkit (EMET) EMET can be used to protect applications that run on all supported versions of Windows. The features included in EMET are specifically designed to break exploitation techniques that are currently used by attackers. 17 Vulnerability Exploitation Trends

19 References Microsoft Exploitability Index Mitigating Software Vulnerabilities The Enhanced Mitigation Experience Toolkit Vulnerability Exploitation Trends 18

20 Appendix: Data Sources and Glossary Data sources This survey used the following data sources: Publicly available, commercially available, and privately reported exploits, including proofs of concept, exploit descriptions, and complete exploit modules. Antimalware telemetry for exploits observed in the wild. The data sources surveyed did not universally provide information about targeted product versions or techniques used by exploits. As such, this portion of the analysis is limited to exploits in which this information was readily available. The antimalware telemetry data that was used in this survey is signature-based and therefore does not constitute proof that a given vulnerability was actually being exploited. Despite this fact, the inclusion of this data provides a more accurate upper bound on which vulnerabilities were actually exploited. Glossary ASLR. An acronym for address space layout randomization, a platform security feature that randomizes the location of code and data in the address space of a process. The first version of Microsoft Windows to support ASLR was Windows Vista in DEP. An acronym for Data Execution Prevention, a platform security feature that prevents data from being executed as code. Exploit. Malicious code that attempts to take advantage of a vulnerability in computer applications or operating systems. Exploitability Index. An index of information created by Microsoft that provides information about the potential exploitability of software vulnerabilities that have been rated as Important or Critical. Microsoft publishes this information for customers who wish to use it for risk analysis purposes. RCE exploit. RCE is an acronym for remote code execution. An RCE exploit is one that enables an attacker to execute arbitrary code of their choosing remotely, without having physical access to the targeted computer. Stack corruption vulnerabilities. Exploitable vulnerabilities that allow the general purpose data structure known as the stack to be corrupted. The stack is that portion of computer memory that is used for storing local variables, function parameters, and other saved register values. Uninitialized memory use vulnerabilities. Exploitable vulnerabilities that occur when a program accesses memory that has not been properly initialized. If exploited, these vulnerabilities could allow remote code execution (RCE). Use after free vulnerabilities. Exploitable vulnerabilities that occur when an object is accessed after it has been freed. Attackers might use such vulnerabilities to cause programs to use their own values, crash programs, or achieve remote code execution (RCE). Vulnerability. A weakness in a product that could allow an attacker to compromise the integrity, availability, or confidentiality of that product. 19 Vulnerability Exploitation Trends