How the Security Development
Lifecycle Helped Improve the
Security of the 2007 Microsoft
Office System
By Tony Rice and Didier Vandenbroeck
March 2, 2010
For the latest information, please see http://www.microsoft.com/sdl
The information contained in this document represents the current view of Microsoft Corporation on
the issues discussed as of the date of publication. Because Microsoft must respond to changing
market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and
Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR
IMPLIED, IN THIS SUMMARY.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in, or introduced into a
retrieval system, or transmitted in any form, by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft
Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, e-mail address, logo, person, place, or event is
intended or should be inferred.
© 2010 Microsoft Corporation. All rights reserved.
Microsoft, SharePoint, SQL Server, Visio, Visual Basic, Visual C#, Visual C++, Visual Studio, the Visual
Studio logo, Win32, Windows, Windows Mobile, Windows Server, and Windows Vista are trademarks
of the Microsoft group of companies.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
TABLE OF CONTENTS
Introduction ............................................................................................. 2
Overview of the 2007 Office system ...................................................... 3
Security Considerations in the 2007 Office system .............................. 3
The Microsoft Office system and the SDL Process ............................... 4
Training Phase ......................................................................................... 5
Requirements Phase ................................................................................ 5
Design Phase ............................................................................................ 5
Implementation Phase ............................................................................ 8
Verification Phase ................................................................................ 100
Response Phase ................................................................................... 111
Conclusions and Results ...................................................................... 122
Acknowledgments ................................................................................. 13
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
1
INTRODUCTION
Security is a critical threat to today’s software industry. According to U.S. Government agencies,
cybercrime is now a US$100 billion business.
(http://resources.mcafee.com/content/NAUnsecuredEconomiesReport).
Software vendors have worked hard to reduce the attack surface of their platforms. Consequently,
attackers have shifted focus to the applications that run on these platforms, while at the same time
becoming much more targeted and stealthy.
Information that the Microsoft Security Response Center (MSRC) has provided indicates that attackers are
increasingly using common file formats such as those found in the Microsoft® Office system as
transmission vectors for exploits. Most modern e-mail and instant messaging programs are configured to
block the transmission of potentially dangerous files, such as those with .exe, .com, and .scr file extensions,
which historically have been misused to transmit malicious software (also called malware). However, these
same programs typically permit the transmission of popular file formats such as those that the Microsoft
Office system uses, including the binary formats doc, xls, and ppt. Many people use these formats
legitimately every day to share information and get work done, so blocking them in modern e-mail or
instant messaging systems is often not practical. As a result, these file formats are an attractive target for
exploitation.
To address general software security concerns, Microsoft developed the Security Development Lifecycle
(SDL). The SDL was designed to reduce as many existing software vulnerabilities as practical and to limit
the severity of any new vulnerabilities that might occur. The SDL is a process that encompasses education,
technology, and executive commitment, to consistently create more secure software.
Although the first version of the SDL dates back to 2002, it was not until 2004 that the Microsoft Senior
Leadership Team decided to require all products with meaningful risk to adopt a standardized SDL. Before
2004, the Microsoft Office team employed its own security best practices, many of which were
incorporated into the SDL. The 2007 Office system was the first Microsoft Office release to include the
standardized SDL process throughout the product development life cycle. This paper summarizes how the
SDL process and the additional security work that the Microsoft Office team carried out has dramatically
improved the security of the 2007 Office system software.
The paper also presents an initial review of how effective these efforts have been. Experience with other
products such as the Windows Server® 2003 and Windows Vista® operating systems, and the Microsoft
SQL Server® 2005 data management software, demonstrates that the first year’s experience has proven
to be a good predictor of the product’s security over the long haul. The 2007 Office system includes much
of the technology contained in earlier releases and this period is considered to be sufficient time for the
security research community to gain familiarity with a new product or technology and to begin to identify
and report the product’s residual vulnerabilities.
Scope
The Microsoft Office system has evolved from a suite of personal productivity products into a
comprehensive and integrated system that includes programs, servers, services, and solutions. These are
designed to work together to help address a broad array of business problems, ranging from personal
productivity to complex project management.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
2
Although the SDL was applied to the entire product suite, the scope of this paper is limited to the
Microsoft Office 2007 suite of products that are most commonly deployed on the desktop: Microsoft
Office Word, Microsoft Office Excel®, Microsoft Office PowerPoint®, and Microsoft Office Outlook®.
The SDL process provides a holistic, comprehensive, and consistent approach to creating secure software.
It is a mandatory part of all software development within Microsoft and increasingly, other organizations
are adopting it, too. This paper does not address every aspect of security within the 2007 Office system;
instead, it concentrates on some specific points that were critical to the success of implementing security
within the Microsoft Office 2007 suite that was mentioned previously.
OVERVIEW OF THE 2007 OFFICE SYSTEM
The core of the 2007 Office system is its desktop personal productivity tools, such as Office Outlook,
Office Excel, Office PowerPoint, and Office Word. These tools have evolved from previous versions of the
2007 Office system. The 2007 Office system has added new features to these programs to enhance how
people can work with one another, partners, and customers. In addition, by building upon the productivity
software skills that people already possess, these programs can enhance the way in which organizations
capture and use information.
No two organizations are the same and different organizations face different challenges. Consequently,
Microsoft offers a variety of suites to address this diverse range of needs.
SECURITY CONSIDERATIONS IN THE 2007 OFFICE SYSTEM
The Microsoft Office system has been available for many years and users have created literally billions of
files by using the various versions of this product. All versions of the Microsoft Office system have to
support the formats that these files use. This means that sweeping changes to the structure of the binary
files are hard to achieve and often risk breaking legacy compatibility; managing backward compatibility
and security is a challenge for each new release of the Microsoft Office system. This combination of a
large customer base, the existence of legacy code, and a need to legitimately use file formats by
applications that are designed to open files that may have originated outside the control of the person
opening them all make Microsoft Office files an attractive attack target. Authors of malware and other
attackers have invested considerable effort in seeking and exploiting any vulnerabilities exposed by the
formats that these files use.
As the attack surface of platforms was reduced and operating systems became more difficult to attack, the
Microsoft Office system was one of the first applications to receive attention from security researchers,
leading to Microsoft releasing several security updates for reported vulnerabilities. Information obtained
from analysis of the vulnerabilities reported to the MSRC, the techniques used to find these vulnerabilities,
and crash data collected from the Microsoft Error Reporting Service were used to identify underlying
security concerns that should be addressed.
This analysis was then used to identify some of the security investments beyond the SDL that the
Microsoft Office Trustworthy Computing (TWC) team would make. Areas identified for investment
included the document file formats that previous versions of the Microsoft Office system used, the
development of code libraries and classes used to mitigate some buffer and integer overflow attacks,
advanced testing of file parsers, and a Privacy feature that can optionally remove some metadata from
files before sharing:
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
3




Document formats:
o FileBlock
o New Document Formats
Code/Runtime Mitigations:
o SafeINT C++ Library
o BoundedPtr Template Class
o Office Automated Code Review
Testing:
o Distributed File Fuzzing
o Active-X Fuzzing
Privacy:
o Document Inspector
These and a number of key SDL activities are discussed in more detail through the following sections.
THE MICROSOFT OFFICE SYSTEM AND THE SDL PROCESS
There are more than 50 requirements in the SDL process that apply to the phases in the development
process: design, implementation, verification, release, and post-release. The requirements and
recommendations of SDL are not static; they are added and changed on a regular basis in the light of
emerging threats and improvements to supporting infrastructure, tools, and processes. The following
image shows the stages in the SDL process.
Some of the tools and techniques that are used to support the SDL process have been released externally.
These include SDL Description, The Microsoft SDL Threat Modeling Tool, Static Code Analysis in Visual
Studio® 2005, SDL Process Template for Visual Studio Team System 2008, and the Binscope Binary
Analyzer. It is possible to download these tools and others from the Microsoft SDL Tools Repository
(http://www.microsoft.com/security/sdl/getstarted/tools.aspx).
As of 2004, meeting the SDL requirements became part of the release policy for all products in Microsoft,
and each major product goes through a Final Security Review in the Release stage to ensure that it is
compliant with security requirements.
In addition to passing the Final Security Review of the SDL process, the team developing the 2007 Office
system also implemented other emerging SDL requirements, such as address space layout randomization
(ASLR), which did not become official SDL requirements until late in the development life cycle.
The SDL process is constantly evolving to take account of the changing threats to software, how software
is used, and advances in technology. The SDL process is updated regularly as the security environment
and the threats posed to applications evolve. These updates incorporate best practices and tools that
support secure software development. The experiences of the Microsoft Office team have contributed to
the evolution of the SDL.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
4
The following sections describe the most important stages of the SDL as applied to the 2007 Office
system, and some of the innovations that the Microsoft Office team introduced.
TRAINING PHASE
Considerable effort was dedicated to training program managers, developers, and testers on the SDL
process, requirements, and tools. In addition, an analysis of the security vulnerabilities reported to the
MSRC and found in the Microsoft Error Reporting Service crashes pointed to some patterns in coding
practices that could lead to security vulnerabilities and should therefore be avoided. The Microsoft Office
TWC team developed over 40 hours of specific customized training that aimed to identify and avoid these
specific security mistakes in both new and existing code.
The customized training that they developed included instructor-led, hands-on courses that guided
attendees through the SDL process step by step, advanced threat modeling concepts, advanced fuzzing
techniques, comprehensive code auditing, and best practice secure code development over and above
the requirements of the SDL process.
This training has been added to the catalog of approved SDL training in Microsoft, enabling other product
teams in Microsoft to benefit from the Microsoft Office team’s experience.
REQUIREMENTS PHASE
The optimal point to specify security requirements for a software project is during the initial planning
stages of a new release or a new version. This enables development teams to identify key objectives and
integrate security in such a way that it is a fundamental tenet of the design and minimizes any disruption
to product plans and development schedules if security requirements are specific later in the process.
Analysis of Known Security Vulnerabilities
To support the SDL process and to aid the prioritization of security investments, the Microsoft Office team
analyzed the vulnerabilities reported through the MSRC, researched the techniques that the security
researchers used to find these vulnerabilities, and also reviewed Microsoft Error Reporting Services
crashes that indicated an underlying security concern.
After triaging and categorizing the issues, several security improvements were recommended. These
recommendations specified which areas to concentrate on through threat model reviews, vulnerability
reviews, and code reviews.
This analysis was an ongoing process. Late in the release cycle, when it became clear that parser attacks
were becoming a major problem, other security investments were made including the development file
block feature and the distributed fuzzing framework.
DESIGN PHASE
During the Design phase, a careful review of customer requirements and expectations regarding security
can help identify portions of the software that may pose risks. It is also important to consider security and
privacy concerns carefully and at an early stage when you design features and to avoid attempts to add
security and privacy near the end of a project’s development. The Microsoft Office TWC team mandated
the use of a specification template that included a section for describing how the feature would be
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
5
implemented as a secure feature. This phase also included performing threat modeling to understand and
document the specific threats posed against the applications in the 2007 Office system. Threat modeling
is a systematic process that is used to identify potential threats and vulnerabilities in software so that
appropriate mitigations and protections can be designed into the software. A team cannot build secure
software unless it understands the assets that the product or service is trying to protect, the threats that
are inherently present when customers deploy it, and the threats in the environment in which it is
deployed.
Threat Modeling for the 2007 Office System
Unlike pure verification techniques, such as penetration testing or fuzzing, threat modeling can be
performed before a product has been implemented in code. This code independence is one of its chief
advantages, enabling it to be performed from the earliest design phases of a project. This helps develop a
product that is secure by design, with minimum reliance on costly post-verification or even post-release
security fixes.
Starting with a preliminary vision of the design in data flow terms, a model is constructed. This usually
takes the form of a diagram. From the diagram, potential threats are then identified and for each threat,
mitigations are proposed. In some cases, the mitigation takes the form of changing the design itself, in
which case the new or changed elements must be analyzed in an additional iteration.
Defining a threat model requires the identification of all possible threats against a given application and
then documenting their assessed probability in addition to potential countermeasures. Following a simple
process, each threat is identified by a threat type in the Spoofing, Tampering, Repudiation, Information
disclosure, Denial of service, or Elevation of privilege (STRIDE) model and is also given a severity rating,
which is derived from MSRC bulletin rating classifications.
Although this process sounds simple, if it is applied thoroughly, it enables many security issues to be
caught early on in the design phase before coding starts. In addition, focus areas for mitigations are
identified, for example, threat models provide fuzzing targets. Often, design or code changes are made
based on the results of threat modeling.
The creation and definition of the 2007 Office system threat models played a significant role in its
development as a secure product. The Microsoft Office TWC team developed a threat-modeling tool that
was used to produce hundreds of threat models for the 2007 Office system. Many were revised and
updated constantly. Analysis of the threats led to the development of a number of mitigations including
the ability to prevent applications from opening file formats if they could pose a threat, and the ability to
remove metadata from documents, addressing a privacy concern in the 2007 Office system.
Due to the size of the product and the number of developers, the Microsoft Office TWC team also built a
custom infrastructure based on Microsoft Office SharePoint® Server and Microsoft Office InfoPath® to
centrally collect and track completion of threat models for the 2007 Office system rather than use the
basic SDL Thread Modeling tool. Over 1,500 threat models were created for the 2007 Office system,
uncovering close to 8,000 vulnerabilities.
Microsoft has since released a more up-to-date version of the SDL Threat Modeling Tool. The SDL Threat
Modeling Tool is an easy-to-use graphical tool for creating and analyzing threat models, capturing impact
assessments and their proposed mitigations, and producing actionable reports and bugs to ensure that
vulnerabilities are mitigated or eliminated.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
6
Implementing New File Formats
Attackers are using vulnerabilities in document file formats as an infection technique in much greater
numbers than in the past.
File formats that the 2003 version and earlier versions of the Microsoft Office System used were both
complex and difficult to understand, properties that the attackers exploited by carefully crafting malicious
documents. Although it was primarily designed for improved clarity and to provide a simplified file format,
the Office Open XML that the 2007 Office system implemented (also referred to as OOXML or OpenXML)
derives security benefits by dramatically reducing the chance of a security vulnerability in the parser.
The new OOXML format is standardized (ISO/IEC 29500:2008, Information technology—Office Open XML
formats) and schema based. Files created by using this format consist of a .zip archive that contains XML
documents and other resources. The parsers for these new formats have been written from the ground up
with security in mind, and have been extensively tested for security vulnerabilities. This testing included a
massive fuzzing effort described in the Verification Phase later in this document.
The OOXML file formats also help to improve security against documents that contain embedded code or
macros. Default documents in the 2007 Office system that are saved in Office XML formats are intended
to be macro-free files, and therefore cannot contain code. This behavior helps to ensure that malicious
code residing in a default document can never be executed unexpectedly. If a code-specific part is found
in a macro-free file, whether placed there accidentally or maliciously, the applications in the 2007 Office
system will not allow the code to execute—without exception.
Documents in the 2007 Office system that are saved in the Office XML format can still contain and use
macros. However, these files must first be saved as a macro-enabled document type. Macro-enabled files
have the same file format as macro-free files, but contain additional parts that macro-free files do not. The
additional parts depend on the type of automation found in the document.
Blocking Files
Attackers frequently use vulnerabilities in document file formats in legacy Microsoft Office file formats as
an infection technique. Most modern e-mail and instant messaging programs are not configured to block
the file formats used by the Microsoft Office suite of programs.
The Microsoft Office TWC team designed a solution that enables a Microsoft Office application to block
certain file types. There are two types of settings for blocking files:


Block open settings, which prevent users from opening various file types and formats. To achieve
this, the file block feature parses a portion of the file and attempts to determine its format
without referring to the extension. It then decides whether to open the file.
Block save settings, which prevent users from saving files in various file types and formats.
The decision to block a file is based on a list of blocked file formats that is configurable by Group Policy.
By default, when it is enabled, only document formats that are older than Word 6 are blocked from
opening.
File blocking can be used to mitigate zero-day attacks by preventing users from opening specific file types
or file formats that can exploit security vulnerabilities. (Zero-day attacks are so named because they
exploit security vulnerabilities between the time that a security vulnerability becomes publicly known and
the time that the software update to mitigate the potential threat is deployed.)
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
7
File blocking was added to the 2003 Microsoft Office System after its development as part of the 2007
Office system, through Office 2003 Service Pack 2 (SP2).
Document Inspector
Document Inspector is a feature in Office Word, Office Excel, and Office PowerPoint 2007 that enables
users to find and remove hidden data and personal information in their documents. There have been
several cases of information disclosure from hidden metadata with previous versions of the Microsoft
Office System. The Microsoft Office team designed a feature that enables users to remove some of this
information before they share documents. The types of information that can be found and removed are:









Comments, revisions, versions, and annotations.
Document properties and version information such as e-mail headers and document server
properties.
Headers and footers or watermarks.
Hidden text.
Custom XML data.
Hidden rows and columns.
Hidden worksheets.
Off-slide content.
Presentation notes.
IMPLEMENTATION PHASE
The SDL process requires developers to adhere to specific best practices for coding software, and these
practices are enforced by using source code analysis tools. However, although these tools are very useful
and find many vulnerabilities, they are not substitute for using a skilled developer. The following sections
describe some of the tools and practices that the Microsoft Office team has implemented.
Performing Static Code Analysis
Static code analysis tools examine the product source code and uncover patterns and idioms that are
known to be problematic from a security perspective. Although no tool can replace human attention, in
general, automated code analysis can successfully find certain kinds of security vulnerabilities and
complements manual code reviews. The 2007 Office system uses Office Automated Code Review (OACR),
which is a set of tools that identifies security vulnerabilities, suggesting better code and generally
accelerating the development process. This tool runs on the developer’s computer without slowing down
a regular build and without adding additional steps to the build process.
OACR contains numerous options for filtering the warnings that it generates. The Microsoft Office TWC
team configures it to use a comprehensive standard for each option set, ensuring that no critical security
warnings are ignored. OACR is constantly updated with new specifications taken from root cause analysis
(RCA) of reported vulnerabilities that are either found internally or reported externally. Vulnerabilities that
OACR identifies are automatically logged in the bug tracking system.
Some of the Microsoft SDL tools that are used for static code analysis (namely /analyze and FxCop) are
available publicly as part of certain editions of the Microsoft Visual Studio® development system.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
8
Preventing Common Security Problems by Using Compiler and Linker Switches
The Microsoft C++ build tools provide several run-time options that can help mitigate against buffer
overflows. These options were turned on by default for the 2007 Office system. They include:

/GS, which protects function return address and some function parameters such as pointers. It does
this by placing a "security cookie" in the function stack before the local variables area and verifying
the state of the stack before returning from the function.

/SafeSEH (or Safe Exception Handling), which limits the set of potentially executable exception
handlers to only those registered at compile time. This can help prevent execution from being
transferred to an exception handler overwritten by an attacker.

/DynamicBase, which implements ASLR. This switch causes the linker to mark the header of the
executable image so that it loads at randomly rebased locations in memory. This makes it more
difficult for an attacker to predict the addresses of key elements within the image.
These switches are available in the Visual Studio C/C++ 2008 set of Microsoft software development tools
and are beneficial for security in virtually any C/C++ application.
In addition, the SafeINT C++ library that David LeBlanc developed was implemented to prevent integer
overflow vulnerabilities. These vulnerabilities can arise when trying to handle sizes that are not validated
when calculating the length of buffers and arrays during the process of memory allocation. SafeINT has
proved to be effective, and not just for products in the 2007 Office system; it is also used extensively in
other Microsoft products and has been released publically through CodePlex.
Although none of these protection mechanisms is a “silver bullet,” these steps make it more challenging
for attackers to predictably exploit issues that might remain in the residual code.
Analyzing Microsoft Error Reporting Service Crashes for Buffer Overflow Issues
The Microsoft Error Reporting Service identifies issues associated with errors trapped by using the /GS
switch, and provides evidence where a buffer overflow occurred in code. It confirms that a buffer overflow
occurred while a customer was using the product.
The /GS compiler option mitigates many types of exploits, but not all of them. If a buffer overrun is
reported, it must be fixed in the code. The Microsoft Office team triaged and fixed all /GS security issues
identified as exploitable that were reported against earlier versions of the Microsoft Office system.
Avoiding Banned Functions
The SDL identifies several functions that, although they were fine when they were first developed, are no
longer considered safe to use given today’s threats. The list of the functions that the SDL has banned
derives from experience of MSRC cases and is largely concerned with preventing buffer overruns. The
Microsoft Office TWC team has extended the list of functions barred from use in the 2007 Office system
and is progressively pushing this policy through and extending the list during each development cycle.
Using BoundedPtr
BoundedPtr is a template class that can help to prevent buffer overflow attacks. It acts like a regular
pointer except that it knows the size of the buffer to which it points, and will block attempts to use the
pointer to access memory outside this buffer. It is intended to be a “drop-in” replacement for a regular
pointer so that retrofitting old code generally involves only changing the declarations of the pointers. For
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
9
example, you can replace int * with BoundedPtr<int>, and then specify the buffer size when you
create the buffer.
Similarly, the BoundedArray template class acts just like an array definition, but has the same range
checks as BoundedPtr. For example, you can replace int rgTemp[10] with BoundedArray<int,
10> rgTemp.
These classes are intended to make securing old legacy code easier. Rather than having to go through
every routine carefully checking for buffer overflows, it is sufficient to convert all of the buffers, and
pointers to those buffers, to BoundedPtr. Then, when an out-of-bounds check happens, the process is
halted rather than enabling the insecure behavior to happen.
VERIFICATION PHASE
Security testing is a critically important part of the SDL process. It addresses two primary concerns:

Security features and functionality that are specifically designed to provide confidentiality,
integrity, and availability of the software and data processed by the software.

Overall quality of the software to help ensure that it is free from deficiencies that could result in
security vulnerabilities. For example, a buffer overrun in code that parses data could possibly be
exploited in several ways that might have security implications.
To address these concerns, the verification phase included several security reviews and tests, which are
described in the following sections.
Directed Code Reviews
In addition to performing the OACRs, the Microsoft Office TWC team regularly reviewed code for security
vulnerabilities.
Manual code reviews require significant skill and a reviewer must be aware of all possible bug
permutations. Even more importantly, a reviewer must be able to recognize these permutations among
thousands or even millions of lines of code. Therefore, it is vital to be able to identify the code that needs
review.
Using information from MSRC cases, feature specifications, and tribal knowledge, a list of areas that are
interesting from a security standpoint was created. Based on this list, the Microsoft Office TWC team
conducted several developer code review sessions looking for both problematic patterns in the code and
specific issues in security-critical code. This review identified several issues that were fixed.
Fuzz Testing
Fuzz testing is a technique of testing applications by feeding the application data that is deliberately
malformed, corrupted, or sometimes just random, and seeing how they behave. It is especially effective in
discovering buffer overflows in C/C++ code processing untrusted input, such as a file parser that opens
files.
The SDL requires a certain amount of fuzzing to be performed on data parsers before release (100,000
clean iterations). The Microsoft Office team went way beyond the minimum required number of fuzzing
iterations, exceeding it by a factor of over 10 times in many cases. To achieve this, the team built upon
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
10
and automated several SDL tools and developed the Distributed Fuzzing Framework (DFF), which took
advantage of the Microsoft Office performance lab.
The DFF enables teams to easily find, track, and regress fuzz bugs in Microsoft applications without being
a security expert. Using the DFF, a development team can quickly complete fuzzing iterations, manage
results, and automate the logging of issues. A fuzz run can be scheduled with the DFF’s central controller
specifying what application should be tested, the fuzzer automation that should be used, and how many
iterations should be performed. As the fuzzing automation runs, results are communicated to the
controller, enabling real-time issue reporting, logging, and investigation.
The DFF is not restricted to one type of fuzzer. Almost any fuzzer that can be launched through the
command line can be configured to run in the DFF. The 2007 Office system used several different fuzzing
tools and techniques, both internal and external to Microsoft.
The DFF assisted in finding many bugs, and the success of this effort reveals that persistence is really
paying off; more and more iterations improved the odds of finding new failures. This benefited not only
the 2007 Office system but also Office 2003 SP3, because the Microsoft Office team could confidently port
back fixes to problems found in legacy parsers.
ActiveX Testing
During the development process of the 2007 Office system, ActiveX® controls for it underwent millions of
fuzzing iterations. The ActiveX controls were fuzzed by using a variety of ActiveX control fuzzers, including
fuzzers built internally and made by third parties. Traditional fuzzers detect errors almost solely by finding
access violations. In addition to using traditional fuzzers, some of the ActiveX fuzzers that were used could
also detect errors where a control does not comply with the Component Object Model (COM)
specification. This level of testing helped the 2007 Office system to carry more robust and secure controls.
In addition to automated fuzzing efforts, ActiveX controls in the 2007 Office system were also the target
of internal penetration testing that the Microsoft Office TWC team performed. The security focus on
ActiveX controls in the 2007 Office system far exceeded similar efforts in previous releases of the
Microsoft Office System.
Internal Penetration Testing
The Microsoft Office System has a dedicated team of internal penetration testers who focus on testing
security features implemented by the product team, such as File block, and the features known to be
susceptible to security issues, such as file parsers. The team is writing internal tools for identifying
vulnerabilities and also helps develop better smart fuzzers, which are used in the DFF. In addition, this
team helps the various development teams to reproduce security problems and write proof-of-concept
exploits.
RESPONSE PHASE
Despite the best engineering efforts and diligently following the SDL, it is inevitable that code defects will
exist and that some of these could lead to security vulnerabilities. The Security Response Plan is designed
to prepare for this contingency. The Microsoft Office team often revisits the security response plan to
determine whether it is possible to make improvements and to address new classes of vulnerabilities
when they arise. This is done on a regular basis and is not tied to a specific release.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
11
CONCLUSIONS AND RESULTS
To summarize, in addition to meeting its SDL commitment for the 2007 Office system, the Microsoft
Office team has stepped up to the challenge and gone beyond the minimum bar described in the SDL in
several areas. The major innovations are:

ASLR. The Microsoft Office team implemented ASLR in the 2007 Office system before this was a
requirement for all Microsoft products. It has continued to exercise vigilance to make sure that
any other libraries released after the 2007 Office system also implement ASLR.

SafeINT. David LeBlanc has been instrumental in developing the SafeInt libraries, which help
mitigate integer overflow. The latest version of SafeInt is available on Codeplex
(http://www.codeplex.com/SafeInt).

Fuzz testing. Binary file formats have been under active attack for several years, so the Microsoft
Office team designed, developed, and deployed the DFF. The DFF has been used extensively on all
supported file formats, including nonbinary formats that applications in the 2007 Office system
use. This has provided improved code coverage for fuzzing and reached new heights for fuzzing
iterations (which are now in the many millions of runs) and fixed bugs. This effort helped make
the new file format safer for Microsoft customers.
As a result of these efforts and following the SDL process, as of August, 2009 (31 months after the
release), the 2007 Office system has had only three public security vulnerabilities reported against the new
file formats. One was in Office Excel and the other two were in Microsoft Office Publisher 2007. During the
same period, 59 security vulnerabilities were reported against the legacy file formats that older versions of
the Microsoft Office System were using.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
12
The figures in the following graph demonstrate that a consistent application of the SDL process and
adoption of security best practices reduces the number of security issues contained in a software product.
Bulletin and CVE comparison
160
140
120
100
80
60
40
20
0
Office
2000 SP3
Bulletins
55
CVE
147
Office XP
SP3
53
Office
2003 SP3
19
Office
2007
17
Office
2007 SP1
16
Office
2007 SP2
3
153
52
35
35
7
In addition, the inclusion of extensive developer training, expanded and improved cryptographic support,
and advanced (OOXML) file formats all demonstrate the commitment to security made by the Microsoft
Office team.
ACKNOWLEDGMENTS
The authors would like to express their gratitude to the Microsoft Office TWC team for its contribution to
this paper and for its help in reviewing it, especially Ambrose Treacy, Ben Canning, Tom Gallagher, and
David LeBlanc.
How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System
13