Office 2007 SDL Whitepaper

8/9/2019 Office 2007 SDL Whitepaper

1/15

How the Security DevelopmentLifecycle Helped Improve theSecurity of the 2007 Microsoft

Office System

By Tony Rice and Didier Vandenbroeck

March 1, 2010

For the latest information, please see http://www.microsoft.com/sdl


2/15

How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System

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 aretrieval 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.


3/15

How the Security Development Lifecycle Helped Improve the Security of the 2007 Microsoft Office System 1

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


4/15


INTRODUCTION

Security is a critical threat to todays 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 orinstant 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 years experience has proven

to be a good predictor of the products 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 products 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.


5/15


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 byapplications 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:


6/15


y Document formats:o FileBlocko New Document Formats

y Code/Runtime Mitigations:o SafeINT C++ Libraryo

BoundedPtr Template Class

o Office Automated Code Reviewy Testing:

o Distributed File Fuzzingo Active-X Fuzzing

y 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 developmentprocess: 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.


7/15


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 teams 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 projects development. The Microsoft Office TWC team mandated

the use of a specification template that included a section for describing how the feature would be


8/15


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 isdeployed.

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.


9/15


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 technologyOffice 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 executewithout 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 asan 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:

y Block open settings, which prevent users from opening various file types and formats. To achievethis, 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.

y 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.)


10/15


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 beenseveral 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:

y Comments, revisions, versions, and annotations.y Document properties and version information such as e-mail headers and document server

properties.

y Headers and footers or watermarks.y Hidden text.y Custom XML data.y Hidden rows and columns.y Hidden worksheets.y Off-slide content.y 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 AnalysisStatic 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 developers 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.


11/15


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:

y /GS, which protects function return address and some function parameters such as pointers. It doesthis 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.

y /SafeSEH (or Safe Exception Handling), which limits the set of potentially executable exceptionhandlers to only those registered at compile time. This can help prevent execution from being

transferred to an exception handler overwritten by an attacker.

y /DynamicBase, which implements ASLR. This switch causes the linker to mark the header of theexecutable 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 integeroverflow 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 overflowoccurred 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 todays 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


12/15


example, you can replace int * with BoundedPtr, 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 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:

y Security features and functionality that are specifically designed to provide confidentiality,integrity, and availability of the software and data processed by the software.

y Overall quality of the software to help ensure that it is free from deficiencies that could result insecurity 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 indiscovering 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


13/15


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 DFFs central controller

specifying what application should be tested, the fuzzer automation that should be used, and how manyiterations 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 theMicrosoft 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 PHA

SE

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.


14/15


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:

y ASLR. The Microsoft Office team implemented ASLR in the 2007 Office system before this was arequirement 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.

y SafeINT. David LeBlanc has been instrumental in developing the SafeInt libraries, which helpmitigate integer overflow. The latest version of SafeInt is available on Codeplex

(http://www.codeplex.com/SafeInt ).

y Fuzz testing. Binary file formats have been under active attack for several years, so the MicrosoftOffice 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 makethe 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.


15/15


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.

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.

0

20

40

60

80

100

120

140

160

Office

2000 SP3

Office XP

SP3

Office

2003 SP3

Office

2007

Office

2007 SP1

Office

2007 SP2

Bulletins 55 53 19 17 16 3

CVE 147 153 52 35 35 7

Bulletin and CVE comparison