msrc progress report 2012

7/31/2019 MSRC Progress Report 2012

1/33

microsoft.com/ms

Building a Safer, More Trusted Internet

Through Information Sharing

Microsoft Security Response Center

Progress Report

July 2011 June 2012

A report from the Microsoft Security Response Center (MSRC) on the progress of various initiatives

that share information to foster deeper industry collaboration, increase community-based defenses,

and better protect customers. This report also includes an update on the Microsoft BlueHat Prize.


2/33

MSRC PROGRESS REPORT 2012 1

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 2012 Microsoft Corporation. All rights reserved.

The names of actual companies and products mentioned herein may be the

trademarks of their respective owners.


3/33


4/33


Table of Contents

Foreword .................................................................................................................................................. 4Microsoft Security Bulletin statistics .............................................................................................. 5

MS11-100: Behind the scenes with an out-of-band security bulletin ......................... 7Microsoft Active Protections Program ....................................................................................... 12

More than just information sharing ....................................................................................... 13Microsoft Active Protections Program partner feedback .............................................. 14

Microsoft Exploitability Index ........................................................................................................ 16Microsoft Exploitability Index statistics ................................................................................. 18

Microsoft Vulnerability Research .................................................................................................. 20MSVR advisories ............................................................................................................................. 20MSVR program statistics ............................................................................................................. 22Coordinated Vulnerability Disclosure .................................................................................... 23

Microsoft BlueHat Prize contest ................................................................................................... 26The Enhanced Mitigation Experience Toolkit (EMET) ..................................................... 27

Conclusion ............................................................................................................................................. 30


5/33

4 MICROSOFT SECURITY RESPONSE CENTER

Foreword

Welcome to the Microsoft Security Response Center (MSRC) annual progress report,

which covers the 12 months ending in June 2012. This report provides an update on

key MSRC programs and projects, and provides analysis of some of the work that the

MSRC and its ecosystem partners have done over the past year. For example, weve

helped address 96 vulnerabilities affecting 39 different vendors using coordinated

vulnerability disclosure and our Microsoft Vulnerability Research Program. And

through the use of the Exploitability Index, customers can make better risk decisionsand potentially reduce the number of security updates that require rapid deployment

by up to 76 percent.

One of the MSRCs most exciting activities this year was the announcement of the

inauguralBlueHat Prize. The Prize challenged security researchers to design a novel

runtime mitigation technology designed to prevent the exploitation of memory

safety vulnerabilities. By the time the contest closed in April 2012, we received 20

qualifying entries (and answered a lot of questions from researchers and potential

participants). It was great to see such innovative thinking taking place in the field of

software security research. When we announce the winner at Black Hat USA 2012,

one of the finalists will walk away with a check for US $200,000!

Although the submissions and the responses have been impressive, we didnt stop

at a contest. This week we are releasing a new beta version of the freely available

Enhanced Mitigation Experience Toolkit (EMET)tool that will incorporate some

of the technology designed by one of our BlueHat Prize finalists. The fact that the

BlueHat Prize has gone from initial announcement to real protection for customers

within a single calendar year shows the positive impact that is possible through

collaboration within the security community.

Also in this report is a look at how the MSRC responds when a serious security

threat appears. If youve ever wondered what happens behind the scenes in one of

these events, heres your chance to find out.

Mike Reavey

Senior Director, Microsoft Security Response Center
http://www.bluehatprize.com/http://www.bluehatprize.com/http://www.bluehatprize.com/http://support.microsoft.com/kb/2458544http://support.microsoft.com/kb/2458544http://support.microsoft.com/kb/2458544http://www.bluehatprize.com/


6/33


Microsoft Security Bulletin

Statistics

The most publicly visible work that the Microsoft Security Response Center

(MSRC) performs is coordinating the development, testing, and release of

Microsoft security updates that address vulnerabilities in Microsoft software. This

section describes some of the key vulnerability trends involving Microsoft software

during the 12 months from July 2011 through June 2012. It provides some

forward-looking thoughts on future trends, and highlights tools and processes thatorganizations can use to help minimize the potential for disruption caused by

security update deployment.

Vulnerabilities are weaknesses in software that enable an attacker to compromise

the integrity, availability, or confidentiality of that software or the data it

processes. Some of the most severe vulnerabilities enable attackers to run code of

their choice, potentially compromising the computer system. The disclosure of a

vulnerability is the revelation of a vulnerability to the software vendor, or to the

public at large. Disclosures can come from various sources, including software

vendors, security software vendors, independent security researchers, and those

who create malicious software (also known as malware).

It is impossible to completely prevent vulnerabilities from being introduced during

the development of large-scale software projects. As long as human beings write

software code, no software will be perfect and mistakes that lead to imperfections in

software will be made. Some imperfections (or bugs) simply prevent the software

from functioning exactly as intended, but other bugs may present vulnerabilities. Not

all vulnerabilities are equal; some vulnerabilities wont be exploitable because specific

mitigations prevent attackers from using them. Nevertheless, some percentage of the

vulnerabilities that exist in a given piece of software could be exploitable.1

Many software developers address vulnerabilities by releasing security updates.

Microsoft has evolved mature and proven processes to help ensure that high-quality security updates are developed, tested, and released in a timely and

1www.microsoft.com/security/msrc/whatwedo/updates.aspx
http://www.microsoft.com/security/msrc/whatwedo/updates.aspxhttp://www.microsoft.com/security/msrc/whatwedo/updates.aspxhttp://www.microsoft.com/security/msrc/whatwedo/updates.aspxhttp://www.microsoft.com/security/msrc/whatwedo/updates.aspx


7/33


predictable manner. See the white paper Software Vulnerability Management at

Microsoft for more details on these processes.

During the 12 months ending June 2012, Microsoft released a total of 90 securitybulletins to address 203 individual vulnerabilities. Software vulnerabilities are

enumerated and documented in the Common Vulnerabilities and Exposures

(CVE) list,2 a standardized repository of vulnerability information.

There was one out-of-band security bulletin released during this period:MS11-

100, published on December 29, 2011. For more information, see MS11-100:

Behind the scenes with an out-of-band security bulletin on page 7.

Figure 1. Bulletins issued and CVEs addressed, 1H071H123

Lower numbers of vulnerabilities that could lead to remote code execution

Vulnerabilities that could lead to remote code execution are potentially the most

dangerous type of vulnerability, because of the level of control they might be able

2cve.mitre.org3 The nomenclature used to refer to different reporting periods is nHyy, where nH refers to either the first (1) orsecond (2) half of the year, andyy denotes the year. For example, 2H11 represents the period covering thesecond half of 2011 (July 1 through December 31), and 1H12 represents the period covering the first half of2012 (January 1 through June 30).

35 3436

42

27

4741

65

5248

42

78

5158

97

85

104

114

153

130

110

93

0

20

40

60

80

100

120

140

160

180

1H07 2H07 1H08 2H08 1H09 2H09 1H10 2H10 1H11 2H11 1H12

CVEsand

Security

BulletinsIssued

Bulletins

CVEs
http://go.microsoft.com/?linkid=9738466http://go.microsoft.com/?linkid=9738466http://go.microsoft.com/?linkid=9738466http://go.microsoft.com/?linkid=9738466http://technet.microsoft.com/security/bulletin/ms11-100http://technet.microsoft.com/security/bulletin/ms11-100http://technet.microsoft.com/security/bulletin/ms11-100http://technet.microsoft.com/security/bulletin/ms11-100http://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/http://cve.mitre.org/http://technet.microsoft.com/security/bulletin/ms11-100http://technet.microsoft.com/security/bulletin/ms11-100http://go.microsoft.com/?linkid=9738466http://go.microsoft.com/?linkid=9738466


8/33


to provide an attacker over a vulnerable computer. Security bulletins that address

these vulnerabilities are typically issued with a severity level of Critical.

Of the vulnerabilities addressed by Microsoft from July 2011 to June 2012, 50.0percent could allow remote code execution by an attacker, down from 62.8

percent during the previous 12-month period.

Figure 2. Percent of vulnerabilities affecting Microsoft products with potential remote code execution, July 2007June 2012

MS11-100: Behind the scenes with an out-of-band

security bulletin

Most Microsoft security bulletins are released on the second Tuesday of each

month, a consistent and predictable schedule designed to help IT departments

plan security update rollouts in advance and deploy them with minimal

disruption. On rare occasions, when the serious nature of a vulnerability justifies

departing from this schedule, Microsoft releases an out-of-band security bulletin to

address the vulnerability in advance of the next scheduled update.

The decision to release a security update out-of-band is made as part of the

Software Security Incident Response Process (SSIRP). SSIRP is the standard

0%

10%

20%

30%

40%

50%

60%

70%

80%

Jul 2007 - Jun 2008 Jul 2008 - Jun 2009 Jul 2009 - Jun 2010 Jul 2010 - Jun 2011 Jul 2011 - Jun 2012

PercentofVulnerabilitiesAffectingM

icrosoftProducts


9/33


Microsoft process for developing, testing, deploying, and communicating

information about a security update in an emergency.4 A typical SSIRP is a flurry

of focused activity, as engineers at Microsofts corporate headquarters and across

the globe work around the clock to provide customers with the necessaryinformation, guidance, mitigation steps, and tools to react appropriately to a

threat.

In this section, Jeremy Tinder, a program manager with the MSRC, describes the

experience of working on the SSIRP that led to the publication of Microsoft

Security Bulletin MS11-100 out-of-band on December 29, 2011.

It was 8:03 P.M. the day after Christmas and I was winding down for the night after

enjoying the first holiday with my baby girl. My phone buzzed. I checked my mail

and saw a meeting invitation from my manager, Dave Midturi.

Subject: SSIRP Bulletin Draft

Location: Your Office

Time: December 27th, All Day

Hey Jeremy,

I hate to do this but I am going to need a lot of help tomorrow and the day after

drafting a crazy bulletin from scratch.

Thanks,

Dave

I was on call this holiday, and it had been fairly quiet for the most part. We rotate

this duty over the various holidays; I was off for Christmas last year so I decided to

volunteer this year in exchange for taking Thanksgiving off. I had been monitoring

my email all weekend in case something critical came in over the holiday.

This shouldnt be too bad, I thought, pondering the email. Ramping up on the

case and writing the bulletin wont take too long. Little did I realize that I also

needed to draft a security advisory and write the CVEs from three other cases in

the next two days.

4 Seewww.microsoft.com/security/msrc/whatwedo/responding.aspxfor more information about the SSIRP.
http://www.microsoft.com/security/msrc/whatwedo/responding.aspxhttp://www.microsoft.com/security/msrc/whatwedo/responding.aspxhttp://www.microsoft.com/security/msrc/whatwedo/responding.aspxhttp://www.microsoft.com/security/msrc/whatwedo/responding.aspx


10/33


I arrived at work the next day, December 27, just before 7:00 A.M. in order to get a

head start on getting up to speed. When Dave arrived, he briefed me on the

situation. A security researcher was going to discuss the details of a security

vulnerability (later designatedCVE-2011-3414) at a security conference the next

day. This vulnerability concerned a flaw in the way several popular web frameworks

(including ASP.NET, PHP, and Java, among others) processed certain specially

crafted requests. By submitting a large number of these requests to a vulnerable

web server, an attacker could quickly overwhelm the servers processor, causing

performance to degrade to the point of creating a denial-of-service (DoS)

condition. This DoS vulnerability could easily be used to disrupt some very large e-

commerce sites if it were to be exploited.

Given the risk the vulnerability posed to our customers and the timing of theholiday season, it was clear that we needed to act swiftly and put out protections as

quickly as we could. The .NET team had already been working around the clock

through the holiday weekend on a security update that would address the

vulnerability. It was time to bring the release team together to expedite the

publication of the update, and I was jumping in feet first. I had a lot of catching up

to do and not much time in which to do it.

I spent the rest of the morning poring over the notes the .NET team had produced

thus far during their investigation of the vulnerability and development of the

update. We would be meeting with the .NET team later in the day, and I wanted tolearn as much as I could about the root cause, affected software, mitigations, and

workarounds so I would know which questions to ask. Thai food was delivered in

the early afternoon for everyone working on the SSIRP, which allowed me to take a

quick break and refuel.

I met up with the .NET team and some other MSRC folks, and we spent the next

five hours in a meeting room reviewing the security advisory in preparation for

release. Microsoft Security Advisories give us a way to communicate important

security information to customers in cases in which a bulletin-class security update

is not possible or not warranted. In this case, we needed to publish a security

advisory in advance of the upcoming bulletin to help our customers mitigate or

work around the danger while we were still working on the security update.
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3414http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3414http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3414http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3414


11/33


By 6:00 P.M., the security advisory was just about done. The only outstanding

action item was to decide when to release it. We scheduled a meeting 45 minutes

out to discuss the details, allowing time for everyone involved with the release to

travel to the work room from various other buildings around the Microsoft campus.

In the meantime, pizza was being ordered, and I had time to freshen up. I needed

to clear my head after being hard at it for almost 12 hours, so I decided to get in a

short 30-minute run and a shower while everyone gathered. It was just what I

needed. After a few slices of pizza and a bottle of water, I was ready to go for

another half-day.

In the course of the next four hours, the plan changed about four times as details

emerged in real time, requiring me to adjust the advisory here and there as we

identified the best plan to protect customers. We decided that the advisory

(designatedMicrosoft Security Advisory 2659883) would be published the next

morning at 5:30 A.M., timed to coincide with the presentation that the security

researcher would be giving.

We called it quits for the night at 10:00 P.M. or so, and I drove the 60 minutes back

to my house to catch a couple hours of sleep. I was back into the office at 6:30 the

next morning, Wednesday, December 28. With the advisory published, I had a lot

of work to do on the text of the security bulletin itself. Microsoft Security Bulletins

are more extensive than security advisories. They include in-depth information

about the vulnerabilities addressed, affected products, and the accompanying

security update packages, as well as FAQ entries for any known issues that

customers may need to understand.

Security bulletins often address multiple vulnerabilities that affect the same

products or components. In this particular case, we decided that the bulletin we

were putting together would address three other ASP.NET vulnerabilities, in

addition to the hashtable vulnerability we were working on. The update code for

CVEs2011-3415,2011-3416, and2011-3417was already in the release pipeline

and being tested, so adding the hashtable vulnerability to this release vehicle

would be the quickest way for us to ship this update in order to protect customers.My job would be to document these additional vulnerabilities for the bulletin.
http://technet.microsoft.com/en-us/security/advisory/2659883http://technet.microsoft.com/en-us/security/advisory/2659883http://technet.microsoft.com/en-us/security/advisory/2659883http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3415http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3415http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3415http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3416http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3416http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3416http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3417http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3417http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3417http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3417http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3416http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3415http://technet.microsoft.com/en-us/security/advisory/2659883


12/33


I burned through the morning hours with l ittle notice of the things happening

around me. My only break was when Chinese food was delivered to the conference

room. By 4:00 P.M. I had a first draft of the bulletin to share with the team. Afterreceiving feedback, we spent the next several hours incorporating it into the

bulletin and working with our technical writers to clean up some of the language.

Late in the evening I had a bulletin I was satisfied with. By this time, Dave and I

were the only two left in the conference room. Everyone else had left for the night,

and we had worked late enough that the energy-saving lights had automatically

turned off. I normally get to work before the lights turn on for the day but this was

the first time I had ever arrived before they turned on and left after they turned off.

As I was sending my last email and preparing to shut down, I realized that it was

11:55 P.M. and I had been working for more than 17 hours straight. I was

exhausted, and driving home at this time of the night was not going to work,

especially for a guy that normally goes to bed at 9:30 P.M. every day and wakes up

at 4:30 in the morning. I looked over at Dave and said, Dude, Im staying here

tonight. There is no way Im going to make it home tonight.Ive got a call with

a security researcher tomorrow morning at 8 anyway so I cant really sleep in.

Dave was nice enough to call the hotel located across the street and reserve a

room for me. I checked in at 12:30 A.M., took a quick shower and went to bed. The

next day, December 29, I stopped by the hotel front desk at about 7:00 A.M. to

check out, and met the same clerk who had checked me in the night before.

Didnt you just check in? he asked, looking at me quizzically.That was a quicknight.

All in all, it was a pretty exciting week. We pulled some insane hours living in the

meeting room (and let me tell you, it needed a good cleaning when we were

done!), but the work we did made a major difference, which made it all worth it.


13/33


Microsoft Active Protections

Program

Officially launched in October 2008, the Microsoft Active Protections Program

(MAPP)5 supplies Microsoft vulnerability information to security software

providers before each Microsoft monthly security update, as well as before out-of-

band security updates and advisories. By obtaining security vulnerability

information early, partners gain additional time to build software protections for

their customers before Microsoft releases security updates to the public.

Prior to MAPPs launch, security software providers received vulnerability

information at the same time as exploit code writers (approximately 10 A.M.

Pacific Time on the second Tuesday of each month, when Microsoft releases its

monthly security updates). Because it takes time for customers to deploy security

updates, this security update release marked the start of a race between

individuals with malicious intent and security software providersa race in which

one side hurries to develop attacks while the other side rushes to provide interim

customer protections until security updates can be applied.

Results reported by Sourcefire, a world leader in real-time adaptive networksecurity, show that before MAPP, approximately eight hours were needed to

reverse engineer vulnerability information, develop proof-of-concept (PoC) exploit

code, and build protective detection code for the exploit. Eight hours is also about

the amount of time a focused attacker needs to generate malicious exploit code

after a vulnerability is disclosed. With advance access to vulnerability information

through MAPP, Sourcefire reports that their protective process now only takes two

hours, and that their developers only have to write the detection code because

everything else is provided. The result is that protections are typically released

hours ahead of any exploit code, which means that customers are better protected

well ahead of even the most focused attackers.

5 For more information, including a list of MAPP partners, seewww.microsoft.com/security/msrc/collaboration/mapp.aspx
http://www.microsoft.com/security/msrc/collaboration/mapp.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapp.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapp.aspx


14/33


Feedback from MAPP partners shows that the number of users who benefit from

partner signatures ranges from tens of thousands for smaller specialist companies

to hundreds of millions for mass-market vendors. MAPP partners6 represent

global markets for antivirus and intrusion detection and prevention systems, andinclude a mix of medium to large companies that provide active software security

protections7 for consumers and enterprises around the world. Partners include

companies based in North America, Europe, the Middle East, and Asia.

Microsoft security professionals regularly communicate with MAPP members to

understand whether the information it is providing helps them achieve their goal

of protecting their customers. Information from these discussions is continuously

evaluated to ensure the program is meeting its main goal of helping to protect the

mutual customers of Microsoft and security providers.

More than just information sharing

Microsoft operates the MAPP program free of charge for security vendors that

meet the companys minimum requirements regarding the number of customers

they represent and their capability to offer protection. Program applicants are

carefully vetted for compliance with the program criteria before being allowed to

join.8

Each month, Microsoft security engineers work diligently to create information for

MAPP partners that helps them detect the exploitation of security vulnerabilities

in Microsoft products. This data includes, but is not always limited to:

A detailed technical write-up on the vulnerability. A step-by-step process that partners can follow to parse an affected file format,

or network protocol, that identifies which elements need to have particular

values, or exceed specific boundaries, to trigger the security vulnerability.

Information on how to detect the vulnerability, or exploitation thereof (suchas event log entries, or stack traces).

6 For the most current list of all MAPP partners, seewww.microsoft.com/security/msrc/collaboration/mapppartners.aspx.7For information on the term active software security protections, seewww.microsoft.com/security/msrc/collaboration/mappfaq.aspx.8 Seewww.microsoft.com/security/msrc/collaboration/mapp/criteria.aspxfor the MAPP program criteria and tosubmit an application questionnaire.
http://www.microsoft.com/security/msrc/collaboration/mapppartners.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapppartners.aspxhttp://www.microsoft.com/security/msrc/collaboration/mappfaq.aspxhttp://www.microsoft.com/security/msrc/collaboration/mappfaq.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapp/criteria.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapp/criteria.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapp/criteria.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapp/criteria.aspxhttp://www.microsoft.com/security/msrc/collaboration/mappfaq.aspxhttp://www.microsoft.com/security/msrc/collaboration/mapppartners.aspx


15/33


A PoC file that contains the specific condition that will trigger thevulnerability, but is not malicious itself. Partners can use this file to test

detection signatures they develop.

Microsoft provides this information to participating vendors shortly in advance of

the release of a security update. The timeframe is based on partners' ability to

release effective protections and also seeks to limit the risk of the information

being inadvertently disclosed.

After receiving this information, MAPP partners can consult with Microsoft

engineers to discuss detailed steps they can take to detect exploitation of a

vulnerability.

Microsoft also follows up with partner vendors to better understand which

vulnerabilities attackers are exploiting in the wild, and how Microsoft can improve

the guidance it offers partners and the public to account for specific exploitationmethods.

Microsoft Active Protections Program partner

feedback

Partners report that the Microsoft Active Protections Program saves them

considerable time and effort, and that these savings are passed on to customers by

way of more timely and effective software protections. Some feedback Microsoft

has received over the last year includes:

Our strong partnership with MAPP enhances our capacity to deliver timely solutions to

our customers. It gives us the advantage of being in the front row seats in battling future

threats and exploits. I applaud MAPP for their continuing initiatives for improvement,

and for developing new projects for its partners.

Raul Alvarez

Senior Malware Analyst

Fortinet Technologies Inc


16/33


With Microsoft's MAPP program they continue to set the pace of what other large

software companies should be doing from a product security perspective. Working with

partners like us to provide additional details to help protect our mutual customers is just

one of the great things about the MAPP program. This last year has seen a continuedincrease of advanced attacks and partnerships between industry continue to be one of the

better ways to share information and get ahead of these threats.

Marc Maiffret

CTO

BeyondTrust (formerly eEye

Digital Security)

Thanks to MAPP, we can now implement detection for new remote exploits within days

instead of weeks, which is well before the bad guys are using these new exploits.

Bas van Sisseren

Head of Research

Quarantainenet Labs

MAPP provides our researchers with thorough information and shortens our research

time. This allows us to provide reliable and accurate protection to our customers quickly

and efficiently. With the time saved, we are able to focus on other critical non-Microsoft

related vulnerabilities.

Karl Lynn

Juniper Networks

MAPP data provides deep insight into a threat/vulnerability enabling Freescale's

VortiQa IPS team to build protection against these threats and provide the same to our

customers within a short time in a reliable and accurate manner without false alarms.

Srini Addepalli

Chief Software Architect

Freescale


17/33


Microsoft Exploitability Index

Through various communication channels, Microsoft provides customers with

information about the availability of PoC exploit code or active attacks related to

vulnerabilities addressed by Microsoft security updates. The Microsoft

Exploitability Index9 was developed in response to customer requests for

additional information to better evaluate risk; it provides new data on the

likelihood of functioning exploit code being developed so customers have

additional guidance to better prioritize the deployment of Microsoft security

updates.10

The main goal of the Exploitability Index is to help customers prioritize their

security update deployments. This information enables customers to better

identify the security updates that are most important to them and deploy them in

a timely manner. For example, a customer might prioritize addressing an

Important severity vulnerability that is likely to be exploited in the first 30 days

after release of the security update over a Critical vulnerability that is unlikely to

ever be exploited. Although most customers use the severity ratings to identify

which updates are most worthy of their attention, the Exploitability Index offers

additional technical detail that can help security and software deployment teams

maximize the benefit of their security resources.

This detail includes:

The security bulletin ID The bulletin title The CVE ID associated with the specific vulnerability The exploit assessment for code execution on the latest release The aggregate exploitability assessment for code execution on older software

releases

9 For more information on the Microsoft Exploitability Index, seetechnet.microsoft.com/security/cc998259.10Alberts, Bas, A Bounds Check on the Microsoft Exploitability Index (Miami Beach, Fla.: Immunity, Inc.,2008), p.7.
http://technet.microsoft.com/security/cc998259http://technet.microsoft.com/security/cc998259http://technet.microsoft.com/security/cc998259http://www.microsoft.com/downloads/details.aspx?FamilyID=0c6e07b5-43ce-4da1-873e-2d604106574chttp://www.microsoft.com/downloads/details.aspx?FamilyID=0c6e07b5-43ce-4da1-873e-2d604106574chttp://www.microsoft.com/downloads/details.aspx?FamilyID=0c6e07b5-43ce-4da1-873e-2d604106574chttp://www.microsoft.com/downloads/details.aspx?FamilyID=0c6e07b5-43ce-4da1-873e-2d604106574chttp://technet.microsoft.com/security/cc998259


18/33


The Exploitability Index uses three levels to communicate to customers the

likelihood of functioning exploit code being developed. In November 2011

Microsoft changed the level descriptions to simplify and clarify the assessments,

and also added a Denial of Service Exploitability Assessment:

1 Exploit code likely. This rating means that MSRC analysis shows thatexploit code could be created, allowing an attacker to consistently exploit the

vulnerability. For example, an attacker could use the exploit to remotely

execute code repeatedly, in a way that produces the same results each time. This

exploitability would make the vulnerability an attractive target for attackers, and

therefore more likely that exploit code would be created. This designation is

also used for vulnerabilities that are already being actively exploited. Customers

who review the security bulletin and determine its applicability to their own

environment could treat such a vulnerability with a higher priority.

2 Exploit code would be difficult to build. This rating means that MSRCanalysis shows that exploit code could be created, but that an attacker would

likely have difficulty creating the code. Such difficulty might be the result of

the need for expertise and sophisticated timing information, and/or varied

results when targeting the affected product. For example, an exploit could

cause remote code execution, but may only work one out of 10 times, or one

out of 100 times, depending on the state of the computer being targeted and

the quality of the exploit code. Although an attacker may increase the

consistency of their results by having better understanding and control of the

target environment, the unreliable nature of this vulnerability makes it a less

attractive target for attackers. Customers who review the security bulletin anddetermine its applicability within their environment should treat this as a

material update. If they are prioritizing against other highly exploitable

vulnerabilities, they could rank this lower in their deployment priority.

3 Exploit code unlikely.This rating means that MSRC analysis shows thatsuccessfully functioning exploit code is unlikely to be released. It might be

possible for exploit code to be released that could trigger the vulnerability and

cause abnormal functionality, but it is unlikely that an attacker would be able

to create an exploit that could fully exploit the vulnerability. Because

vulnerabilities of this type require significant investment by attackers to be

useful, the risk of exploit code being created and used within 30 days of a

bulletin release is much lower. Therefore, customers who review the securitybulletin to determine its applicability within their environment could

prioritize this update below other vulnerabilities within a release.


19/33


The Denial of Service (DoS) exploitability assessment can reflect either of the

following:

Figure 3. DoS exploitability assessment used by the Exploitability Index

DoS exploitability

assessmentShort definition

Temporary

Exploitation of this vulnerability may cause the operating system or application

to become temporarily unresponsive, until the attack is halted, or to exit

unexpectedly but automatically recover. The target returns to the normal level of

functionality shortly after the attack is finished.

Permanent

Exploitation of this vulnerability may cause the operating system or application

to become permanently unresponsive, until it is restarted manually, or to exit

unexpectedly without automatically recovering.

If a vulnerability could allow a permanent denial of service, it would require an

administrator to start, restart, or reinstall all or parts of the system. It should be

noted that any vulnerability that automatically restarts the system is also

considered a permanent DoS. In addition, client applications that are typically

intended for interactive use, such as Microsoft Office releases, would not get a

DoS Exploitability Assessment.

Its important to note that an Exploitability Index of 1 is not a guarantee that

exploit code will be developed for that specific vulnerability. Events and other

factors in the security ecosystem may make exploitation of a vulnerability

financially unattractive or uninteresting. Over time, however, Exploitability Index

ratings have been a reliable and effective guide to understanding whether or not a

given vulnerability is likely to lead to exploits in the wild.

Microsoft Exploitability Index statistics

The 90 security bulletins Microsoft published from July 2011 to June 2012

resulted in 190 Exploitability Index ratings, as shown in the following table.


20/33


Figure 4. Microsoft Exploitability Index ratings, July 2011June 2012

Exploitability Index rating Latest software release Older software releases

1 - Exploit code likely 104 122

2 - Exploit code would be difficult to build 12 14

3 - Exploit code unlikely 34 20

Not applicable 40 34

Total 190 190

Of the 190 ratings issued from July 2011 through June 2012, none were revised

after release.

An examination of different possible deployment scenarios illustrates how the

Exploitability Index can help save organizations money and allow them to better

allocate resources:

Figure 5. Security bulletin deployment events under different scenarios, June 2011June 2012

Deployment scenario Deployment events

Deploy all bulletins within 30 days 90

Deploy only critical bulletins within 30 days after release 26

Deploy only critical bulletins with an XI of 1 on release day 24

Deploy only critical bulletins with an XI of 1 on release day, when all systems are on the most

recent product release21

For example, a customer that deployed all security bulletins within 30 days would

have had to test and deploy a total of 90 bulletins from July 2011 to June 2012. By

contrast, a customer that only deployed critical updates with an Exploitability Index

rating of 1 and used the most recent Windows client and server versions exclusively

would have deployed just 21 updates, a difference of more than 76 percent.

Microsoft recommends that customers install all applicable security updates,

including bulletins with an exploitability index of 3 or a severity rating of

Moderate. Exploitation techniques change over time, and newly developed

techniques can make it easier for an attacker to exploit vulnerabilities that had

previously been more difficult to successfully exploit. Nevertheless, Microsoft

recognizes that prioritization decisions will be made within each organization and

that time and resources may often be limited. The Exploitability Index allows

customers that face such limitations to better prioritize their update deployments.


21/33


Microsoft Vulnerability Research

In an age in which almost all types of computing devices can be interconnected

with each other, the security and privacy of data is more important than ever. In

addition, the potential consequences of security vulnerabilities can be much more

severe and have a much greater impact on the Internet in general. MSVR was

established to provide a mechanism for Microsoft software developers and security

researchers to share their collective knowledge and experience with third-party

software developers and the greater community. The success of MSVR has helped

improve the security ecosystem as a whole, which benefits Microsoft, othersoftware publishers, and the worldwide community of computer users.

Figure 6. The MSVR response process

MSVR advisories

As part of the CVD approach, the MSVR program issues advisories that provide

details about software vulnerabilities that Microsoft had privately disclosed to

third-party vendors. From July 2011 through June 2012, Microsoft issued 19

MSVR advisories, which are listed in the following figure.


22/33


Figure 7. MSVR advisories issued from July 2011 to June 2012

Advisory Number Advisory Description Date

MSVR11-007 Clickjacking Vulnerability in Facebook.com Could Allow Account Compromise 7/19/2011

MSVR11-008 Vulnerability in Google Picasa Could Allow Remote Code Execution 7/19/2011

MSVR11-009 Vulnerability in Apple Safari Could Allow Information Disclosure 8/16/2011

MSVR11-010 Vulnerability in WordPress Could Allow Cross-Domain Script Execution 8/16/2011

MSVR11-011Vulnerability in FFmpeg Matroska Format Decoder Could Allow Remote Code

Execution9/20/2011

MSVR11-012 Vulnerability in FFmpeg Could Allow Remote Code Execution 10/18/2011

MSVR11-013 Vulnerability in Wireshark Could Allow Remote Code Execution 10/18/2011

MSVR11-014 Vulnerability in Wireshark Allows For Arbitrary Script Execution 11/15/2011

MSVR11-015 Vulnerability in Hex-Rays IDA Pro, IDAPython Plugin Could Allow Arbitrary ScriptExecution

12/21/2011

MSVR11-016 Vulnerability in NVIDIA Stereoscopic 3D Driver Could Allow Elevation of Privilege 12/20/2011

MSVR12-001 Vulnerabilities in XnViewer Could Allow Remote Code Execution 1/17/2012

MSVR12-002 Vulnerability in DotNetNuke Could Allow Arbitrary Script Execution 2/21/2012

MSVR12-003 Vulnerability in DotNetNuke Could Allow Arbitrary Script Execution 2/21/2012

MSVR12-004JPEG 2000 Memory Overwrite Vulnerability in OpenJPEG Could Allow Arbitrary

Code Execution3/20/2012

MSVR12-005 Vulnerabilities in RealNetworks Helix Server Could Allow Arbitrary Script Execution 4/17/2012

MSVR12-006

Vulnerability in RealNetworks Helix Universal Media Server Could Allow Denial of

Service 4/17/2012

MSVR12-007 Apple QuickTime MPEG Parsing Memory Corruption 5/17/2012

MSVR12-008 Vulnerability in Google Chrome Could Allow Local Code Execution 6/19/2012

MSVR12-009 Vulnerability in LongTail Video JW Player Could Allow Cross-Site Scripting 6/19/2012

Microsoft does not reveal vulnerability details to the public before a vendor-

available for issues that are reported though the MSVR program unless there is

significant evidence of active attacks in the wild. If attacks begin before the vendor

has released their remediation, Microsoft will continue to coordinate release of

consistent mitigation and workaround guidance with the vendor. This cooperative

approach ensures that affected customers understand their risk and what to do tomitigate that risk, without revealing details that attackers could use to commit

cybercrime.
http://technet.microsoft.com/en-us/security/msvr/msvr11-007http://technet.microsoft.com/en-us/security/msvr/msvr11-007http://technet.microsoft.com/en-us/security/msvr/msvr11-008http://technet.microsoft.com/en-us/security/msvr/msvr11-008http://technet.microsoft.com/en-us/security/msvr/msvr11-009http://technet.microsoft.com/en-us/security/msvr/msvr11-009http://technet.microsoft.com/en-us/security/msvr/msvr11-010http://technet.microsoft.com/en-us/security/msvr/msvr11-010http://technet.microsoft.com/en-us/security/msvr/msvr11-011http://technet.microsoft.com/en-us/security/msvr/msvr11-011http://technet.microsoft.com/en-us/security/msvr/msvr11-012http://technet.microsoft.com/en-us/security/msvr/msvr11-012http://technet.microsoft.com/en-us/security/msvr/msvr11-013http://technet.microsoft.com/en-us/security/msvr/msvr11-013http://technet.microsoft.com/en-us/security/msvr/msvr11-014http://technet.microsoft.com/en-us/security/msvr/msvr11-014http://technet.microsoft.com/en-us/security/msvr/msvr11-015http://technet.microsoft.com/en-us/security/msvr/msvr11-015http://technet.microsoft.com/en-us/security/msvr/msvr11-016http://technet.microsoft.com/en-us/security/msvr/msvr11-016http://technet.microsoft.com/en-us/security/msvr/msvr12-001http://technet.microsoft.com/en-us/security/msvr/msvr12-001http://technet.microsoft.com/en-us/security/msvr/msvr12-002http://technet.microsoft.com/en-us/security/msvr/msvr12-002http://technet.microsoft.com/en-us/security/msvr/msvr12-003http://technet.microsoft.com/en-us/security/msvr/msvr12-003http://technet.microsoft.com/en-us/security/msvr/msvr12-004http://technet.microsoft.com/en-us/security/msvr/msvr12-004http://technet.microsoft.com/en-us/security/msvr/msvr12-005http://technet.microsoft.com/en-us/security/msvr/msvr12-005http://technet.microsoft.com/en-us/security/msvr/msvr12-006http://technet.microsoft.com/en-us/security/msvr/msvr12-006http://technet.microsoft.com/en-us/security/msvr/msvr12-007http://technet.microsoft.com/en-us/security/msvr/msvr12-007http://technet.microsoft.com/en-us/security/msvr/msvr12-008http://technet.microsoft.com/en-us/security/msvr/msvr12-008http://technet.microsoft.com/en-us/security/msvr/msvr12-009http://technet.microsoft.com/en-us/security/msvr/msvr12-009http://technet.microsoft.com/en-us/security/msvr/msvr12-009http://technet.microsoft.com/en-us/security/msvr/msvr12-008http://technet.microsoft.com/en-us/security/msvr/msvr12-007http://technet.microsoft.com/en-us/security/msvr/msvr12-006http://technet.microsoft.com/en-us/security/msvr/msvr12-005http://technet.microsoft.com/en-us/security/msvr/msvr12-004http://technet.microsoft.com/en-us/security/msvr/msvr12-003http://technet.microsoft.com/en-us/security/msvr/msvr12-002http://technet.microsoft.com/en-us/security/msvr/msvr12-001http://technet.microsoft.com/en-us/security/msvr/msvr11-016http://technet.microsoft.com/en-us/security/msvr/msvr11-015http://technet.microsoft.com/en-us/security/msvr/msvr11-014http://technet.microsoft.com/en-us/security/msvr/msvr11-013http://technet.microsoft.com/en-us/security/msvr/msvr11-012http://technet.microsoft.com/en-us/security/msvr/msvr11-011http://technet.microsoft.com/en-us/security/msvr/msvr11-010http://technet.microsoft.com/en-us/security/msvr/msvr11-009http://technet.microsoft.com/en-us/security/msvr/msvr11-008http://technet.microsoft.com/en-us/security/msvr/msvr11-007


23/33


This coordination takes place under Microsofts approach to coordinated

vulnerability disclosure. CVD clarifies how Microsoft responds as a vendor that is

affected by vulnerabilities in its products and services, as a finder of new

vulnerabilities in third-party products and services, and as a coordinator ofvulnerabilities that affect multiple vendors.

MSVR advisories are posted at

www.microsoft.com/technet/security/advisory/MSVRarchive.mspx. The format of

an MSVR advisory is similar to that of a Microsoft security advisory: each MSVR

advisory contains a top-level summary that states the reason for issuing the

advisory, frequently asked questions, and a Suggested Actions section that

describes any action that users may have to take to help protect themselves. MSVR

advisories may be revised as required to reflect new information or guidance.

MSVR program statistics

Since July 2011, MSVR has identified and responsibly disclosed 96 differentsoftware vulnerabilities affecting a total of 39 vendors.

49 percent of third-party vulnerabilities found through MSVR since July 2011were rated as Critical or Important.11

Of these third-party vulnerabilities, 37 percent have already been resolved.None of the vulnerabilities without updates have been observed in any

attacks.

For more information, see the Microsoft Vulnerability Research page atwww.microsoft.com/security/msrc/collaboration/research.aspx.

11www.microsoft.com/technet/security/bulletin/rating.mspx
http://www.microsoft.com/technet/security/advisory/MSVRarchive.mspxhttp://www.microsoft.com/technet/security/advisory/MSVRarchive.mspxhttp://www.microsoft.com/security/msrc/collaboration/research.aspxhttp://www.microsoft.com/security/msrc/collaboration/research.aspxhttp://www.microsoft.com/technet/security/bulletin/rating.mspxhttp://www.microsoft.com/technet/security/bulletin/rating.mspxhttp://www.microsoft.com/technet/security/bulletin/rating.mspxhttp://www.microsoft.com/technet/security/bulletin/rating.mspxhttp://www.microsoft.com/security/msrc/collaboration/research.aspxhttp://www.microsoft.com/technet/security/advisory/MSVRarchive.mspx


24/33


Coordinated Vulnerability Disclosure

In July 2010, the MSRC announced the formulation of a set of practices to be usedin disclosing information about software vulnerabilities in a way that benefits both

vendors and consumers. Termed Coordinated Vulnerability Disclosure (CVD),

these practices have since been adopted by Microsoft and other software vendors

across the industry.

Use of Coordinated Vulnerability Disclosure (CVD)12 increased to a new high

during the period from July 2011 through June 2012. Of the vulnerabilities

disclosed to Microsoft, 91 percent were reported using CVD, up from 84 percent

during the previous 12-month period.

Figure 8. Vulnerability disclosures affecting Microsoft products, July 2006June 2012

Under CVD, finders disclose newly discovered vulnerabilities in hardware,

software, and services directly to the vendors of the affected product, to a

national/regional CERT or other coordinator who will report to the vendor

privately, or to a private service that will likewise report to the vendor privately.

12 Seeblogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspxfor more information about Coordinated Vulnerability Disclosure.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Jul 07Jun 08 Jul 08Jun 09 Jul 09Jun 10 Jul 10Jun 11 Jul 11Jun 12

Percento

fAllVulnerabilityDisclosures

Full Disclosure

CVD (incl.

vulnerability

broker)
http://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspxhttp://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspxhttp://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspxhttp://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspxhttp://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspxhttp://blogs.technet.com/b/ecostrat/archive/2010/07/22/coordinated-vulnerability-disclosure-bringing-balance-to-the-force.aspx


25/33


The finder allows the vendor the opportunity to diagnose and offer fully tested

updates, workarounds, or other corrective measures before any party discloses

detailed vulnerability or exploit information to the public. The vendor continues

to coordinate with the finder throughout the vulnerability investigation andprovides the finder with updates on case progress. Upon release of an update, the

vendor may recognize the finder in bulletins or advisories for finding and privately

reporting the issue. If attacks are underway in the wild, and the vendor is still

working on the update, both the finder and vendor work together as closely as

possible to provide early public vulnerability disclosure to help protect customers.

The aim is to provide timely and consistent guidance to help customers protect

themselves.

Information about vulnerabilities in third-party products comes to Microsoft

Vulnerability Research (MSVR) in three primary ways:

Internal Microsoft developers and test engineers. In the course of theirday-to-day jobs, developers and test engineers find potential

vulnerabilities in third-party software. These vulnerabilities are reported

to the MSVR team, which then works with the affected vendor to fix the

issue.

Internal research projects. As time and resources permit, MSVRperforms its own vulnerability analysis and research using internally

developed toolsets and practices on third-party products that run on

Microsoft operating systems but are not developed by Microsoft.

External reports to the MSRC. External researchers report issues to theMSRC that they believe affect Microsoft products. On occasion,researchers determine that a reported issue affects third-party products

instead of or in addition to Microsoft products. As with internally

discovered vulnerabilities, these findings are reported to the MSVR team,

which works with the affected vendors to address the issue.

After receiving information about a vulnerability in a third-party product, MSVR

compiles a comprehensive set of information about the vulnerability to provide to

the affected vendor. This information might include details about the test

environment in which the vulnerability was observed, the severity and security

impact of the vulnerability, crash dump information, PoC and/or exploit code,

root cause analysis information, and other technical details about the

vulnerability.


26/33


When the analysis is complete, MSVR initiates communication with the vendors

designated contact, using encrypted email if possible or other methods as

appropriate. To minimize the risk of vulnerability information being misdirected

while attempting to identify the vendor contact, MSVR will not send thevulnerability report in the initial email message. The initial message will be a

simple introduction stating that MSVR is attempting to identify the correct contact

to report a vulnerability in the vendors products or services. When the

appropriate vendor contact is identified and confirms willingness to accept the

vulnerability report, MSVR provides the vulnerability report.

Microsoft understands that each software vendor is likely to have its own list of

concerns about cooperating with other parties on vulnerability response, and that

some software vendors may have misgivings about accepting MSVRs help. MSVR

is pleased to work in a cooperative manner with any vendor to deal with a

software vulnerability on the Windows platform. At the same time, MSVR urgesevery software vendor to address vulnerabilities in an open, responsive, and timely

fashion, whether in cooperation with MSVR or not. Acting in this manner will

help keep the Internet ecosystem safer for all users, and help vendors achieve a

positive reputation in the security community as well.


27/33


28/33


defines a set of checks that can be used to detect when certain functions are

being called in the context of malicious ROP code.

Vasilis Pappas. Pappas is a Ph.D. student at Columbia University in NewYork City who actively researches information security. Pappas submission,

called kBouncer, is a ROP mitigation technique that detects abnormal

control transfers using common hardware features.

On July 25, 2012, Microsoft announced that a portion of one of the finalists

entries would be integrated into the Enhanced Mitigation Experience Toolkit

(EMET; see below). This integration means that customers can already benefit

from protection offered by some of the technology revealed through the BlueHat

Prize contest.

Microsoft is very satisfied with the response of the research community and the

innovative defensive solutions entered into the contest, and will be sharing furtherdetails of the entries after the winners are announced.

The Enhanced Mitigation Experience Toolkit (EMET)

We use only Windows on our desktops, and only with EMET.

Brad Spengler

grsecurity.net

Recent versions of Windows, including Windows Vista and Windows 7, include security

enhancements that make vulnerabilities significantly harder to exploit than in earlier

versions of Windows. Similarly, recent releases of many popular software programs

offer security features that make those releases much less vulnerable to successful

exploitation. Microsoft recommends using the most recent versions of Windows and

applications when practical to do so to take advantage of the built-in security

functionality they offer.

However, in some cases individuals and organizations cannot deploy recent software

versions for a variety of reasons, or want to take advantage of modern security

improvements in advance of a planned upgrade. For these customers, as well as for

users of the latest software versions who want to take advantage of additional security

improvements, Microsoft offers theEnhanced Mitigation Experience Toolkit(EMET)

at no charge from the Microsoft Download Center (www.microsoft.com/download).
http://go.microsoft.com/fwlink/?LinkID=200220http://go.microsoft.com/fwlink/?LinkID=200220http://go.microsoft.com/fwlink/?LinkID=200220http://go.microsoft.com/fwlink/?LinkID=200220


29/33


EMET is a free and reliable solution that can significantly improve your security

level. Not using it at times like these would be a real waste.

Piotr Bania

piotrbania.com

EMET provides system administrators with the ability to deploy security mitigation

technologies such as Address Space Layout Randomization (ASLR), Data Execution

Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), and

others to selected installed applications. These technologies function as special

protections and obstacles that an exploit author must defeat to exploit software

vulnerabilities. These security mitigation technologies do not guarantee that

vulnerabilities cannot be exploited. However, they make exploitation more difficult.

EMET 3.0, the latest version, is compatible with supported versions of Windows XP,Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and

Windows Server 2008 R2. EMET 3.0 eases enterprise deployment via features such as

Group Policy and SCCM support, event logging, configuration profile, and others. The

technical preview version of EMET 3.5 incorporates new mitigation technologies from

the Microsoft BlueHat Prize contest submissions, to mitigate return-oriented

programming (ROP) attacks. (See page 26 for more information about the contest.)

There are 4 new ROP mitigations that are aimed at detecting ROP attacks: stack pivot,

caller checks, execution flow simulation, and special checks on critical functions.

EMET prevents malware from exploiting vulnerabilities, period! There are manydocumented cases showing how EMET blocked new malware found in the wild.

EMET is a must-have for your workstations.

Didier Stevens

Contraste Europe NV and author of HeapLocker

To assess the effectiveness of EMET in addressing a number of commonly exploited

vulnerabilities, Microsoft researchers collected a sample of 184 application exploits

that had been sent to Microsoft from customers worldwide. All exploits targeted

vulnerabilities in popular applications running on one or more versions of

Windows. The researchers tested each exploit against Windows XP SP3 in an out-

of-the-box configuration, Windows XP SP3 with EMET deployed, and the release-

to-manufacturing (RTM) version of Windows 7 in an out-of-the-box configuration.

Figure 9shows the results of these tests.


30/33


31/33


Conclusion

The global computing threat landscape is constantly evolving. The reality is that

no one company, individual or technology can solve todays security challenges

alone. It will take a collective effort. Microsoft has responded to this continuing

shift by developing a series of programs and initiatives that involve responsible

information sharing to help customers manage and overcome threats to computer

security.

The MAPP has partners reporting significant reductions in development timefor delivering protection help to customers, which reduces the amount of time

that computer systems are at risk.

The Microsoft Exploitability Index is now firmly established as a valuable partof the Microsoft monthly security update release cycle, and it helps customers

around the world prioritize their security update deployments and create

more reliable and cost-effective system protection measures.

Through the MSVR program, Microsoft has leveraged its considerable depthof expertise and tools with vendors to help raise the level of security in their

products that run on the Windows platform.

CVD is helping to protect customers around the world from attack whileMicrosoft and other organizations work to build, test, and release high-quality

security updates.

As the criminal landscape also evolves, increased information sharing is key to

advancing progress towards safer, more trusted computing experiences. This

sharing involves continued work to develop better community-based defenses,

increased help to resolve vulnerabilities in highly leveraged third-party code

running on the Windows platform, and empowering customers with information

that helps them make better risk assessments.


32/33


33/33

One Microsoft Way

Redmond, WA 98052-6399

microsoft.com/msrc

msrc progress report 2012

Documents