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.
7/31/2019 MSRC Progress Report 2012
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.
7/31/2019 MSRC Progress Report 2012
3/33
7/31/2019 MSRC Progress Report 2012
4/33
MSRC PROGRESS REPORT 2012 3
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
7/31/2019 MSRC Progress Report 2012
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/7/31/2019 MSRC Progress Report 2012
6/33
MSRC PROGRESS REPORT 2012 5
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.aspx7/31/2019 MSRC Progress Report 2012
7/33
6 MICROSOFT SECURITY RESPONSE CENTER
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=97384667/31/2019 MSRC Progress Report 2012
8/33
MSRC PROGRESS REPORT 2012 7
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
7/31/2019 MSRC Progress Report 2012
9/33
8 MICROSOFT SECURITY RESPONSE CENTER
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.aspx7/31/2019 MSRC Progress Report 2012
10/33
MSRC PROGRESS REPORT 2012 9
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-34147/31/2019 MSRC Progress Report 2012
11/33
10 MICROSOFT SECURITY RESPONSE CENTER
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/26598837/31/2019 MSRC Progress Report 2012
12/33
MSRC PROGRESS REPORT 2012 11
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.
7/31/2019 MSRC Progress Report 2012
13/33
12 MICROSOFT SECURITY RESPONSE CENTER
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.aspx7/31/2019 MSRC Progress Report 2012
14/33
MSRC PROGRESS REPORT 2012 13
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.aspx7/31/2019 MSRC Progress Report 2012
15/33
14 MICROSOFT SECURITY RESPONSE CENTER
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
7/31/2019 MSRC Progress Report 2012
16/33
MSRC PROGRESS REPORT 2012 15
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
7/31/2019 MSRC Progress Report 2012
17/33
16 MICROSOFT SECURITY RESPONSE CENTER
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/cc9982597/31/2019 MSRC Progress Report 2012
18/33
MSRC PROGRESS REPORT 2012 17
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.
7/31/2019 MSRC Progress Report 2012
19/33
18 MICROSOFT SECURITY RESPONSE CENTER
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.
7/31/2019 MSRC Progress Report 2012
20/33
MSRC PROGRESS REPORT 2012 19
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.
7/31/2019 MSRC Progress Report 2012
21/33
20 MICROSOFT SECURITY RESPONSE CENTER
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.
7/31/2019 MSRC Progress Report 2012
22/33
MSRC PROGRESS REPORT 2012 21
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-0077/31/2019 MSRC Progress Report 2012
23/33
22 MICROSOFT SECURITY RESPONSE CENTER
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.mspx7/31/2019 MSRC Progress Report 2012
24/33
MSRC PROGRESS REPORT 2012 23
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.aspx7/31/2019 MSRC Progress Report 2012
25/33
24 MICROSOFT SECURITY RESPONSE CENTER
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.
7/31/2019 MSRC Progress Report 2012
26/33
MSRC PROGRESS REPORT 2012 25
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.
7/31/2019 MSRC Progress Report 2012
27/33
7/31/2019 MSRC Progress Report 2012
28/33
MSRC PROGRESS REPORT 2012 27
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=2002207/31/2019 MSRC Progress Report 2012
29/33
28 MICROSOFT SECURITY RESPONSE CENTER
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.
7/31/2019 MSRC Progress Report 2012
30/33
7/31/2019 MSRC Progress Report 2012
31/33
30 MICROSOFT SECURITY RESPONSE CENTER
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.
7/31/2019 MSRC Progress Report 2012
32/33
7/31/2019 MSRC Progress Report 2012
33/33
One Microsoft Way
Redmond, WA 98052-6399
microsoft.com/msrc