tom gallagher – senior security test lead, office trustworthy computing david conger – software...

Under the Kimono of Office Security Engineering

Tom Gallagher – Senior Security Test Lead, Office Trustworthy Computing David Conger – Software Design Engineer in Test II, Microsoft Access

Agenda History of Office Security Our approach to securing Office Demos of internal tools and protections

in Office 2010.

History of Office Security

Oldest threat Macro viruses

Around 1999 a rash of Outlook attachment issues and ActiveX repurposing attacks.

Prior to 2006, very few malformed documents attacks to corrupt memory (overflows, double free, etc).

Security Org of OfficeMSEC Office TwC

Product 1 Sec

Contacts

Feature Owner

Feature Owner

Feature Owner

Product2 Sec

Contacts

Feature Owner

Feature Owner

Feature Owner

Product3 Sec

Contacts

Feature Owner

Feature Owner

Feature Owner

Product4 Sec

Contacts

Feature Owner

Feature Owner

Feature Owner

Office SE (CAPES)

Layered Defenses

Harden the

Attack Surface

Reduce the

Attack Surface

Improve User

Experience

Mitigate the

Exploits

Harden Attack Surface

SDL Compliant OACR (Automated Code Review

Tool) SafeInt Remove old parsers Intensive Distributed Fuzzing

Harden the

Attack Surface

Office’s fuzzing surface

HUGE! 300+ file formats

Many formats may not be obvious at first Example: WPD files could be parsed by 3 different parsers

Specialized “smarter” fuzzers for many formats

Different fuzzers find different bugs Experience in line with BlueHat Fuzzing Olympics results

and Charlie Miller’s 2008 CanSecWest presentation.

Before the Distributed Fuzzing Framework….

Managing SDL compliance gets messy…. Each team has a subset of the supported

formats. Unclear how many iterations completed

by each. Machine logs often duplicate failures

Across machines, runs, formats (core failures) Best practices not centralized and shared

Machine Resources

Leverage machines in testers offices Machines manually configured. Testers often needed to use these machines

for their normal test passes. Became a bottleneck for completing fuzz runs No easy way to leverage unused resources.

If one team finishes their fuzzing passes, they need to manually find out who might need help and how to config those runs. (Doesn’t happen.)

Distributed Fuzzing Framework Goals Teams don’t need to manage hardware. Use any machine with Office installed for fuzzing. Machines join in fuzzing of multiple products/runs. Run any fuzzer. Simple run definition. Automate regression of previously found crashes. Centrally manage all fuzzing jobs. Detect duplicate crashes across runs and in

Product Studio. Automate logging crashes to bug database..

- Hardware and Multiple Products

Teams can dedicate their

existing testing resources.

Existing lab resources can

be shared across multiple

teams and products.

DFF infrastructure is managed by TwC and DFF Admins.

Teams in Office can use DFF without supplying any hardware resources.


Contribute to a specific team’s effort or every

team.Additional settings also make the Client easier for team members to

use on their test machine(s).

Simple controls make it easy for

team members to contribute their

machine(s).


Status and settings can be controlled

from the web. Move machines easily between

Teams and Runs.Some machines are dedicated to specific products,

some contribute in any available

product.


Product Studio. Automate logging crashes to bug database.

- Fuzzers, Runs, and Regression

Hundreds of Fuzzer configurations across many

different types of fuzzers are available.


Any fuzzer (or tools that generates

files) can be used in DFF.

A fuzzer in DFF can be diff of another

fuzzer.

More than just random mutation

file fuzzing. Distribute an

ActiveX or sequential fuzzer.


Choose fuzzers and templates from simple

lists of system wide and team defined fuzzers and

templates.

Fuzz against on the version you are ready to test.

Define runs that run once or

multiple times.

Easily define a run to retest all previous failures based on a

Call Stack or Bug, with failures found in any

product using a matching

configuration.

DFF aids with machine throttling for less powerful

machines.

Distributed Fuzzing Framework Goals Teams don’t need to manage hardware. Use any machine with Office installed for fuzzing. Machines join in fuzzing of multiple products/runs. Run any fuzzer Simple run definition. Automate regression of previously found crashes. Centrally manage all fuzzing jobs. Detect duplicate crashes across runs and in


- Centrally manage all fuzzing jobs

Control a runs stats (Queued, Private,

Disabled) or modify its settings..

See progress and machine allocation all on one page.

Begin investigating failures as soon as they are found.

On top of only seeing runs you own, you can filter active runs to

see only what you care most about.

- Centrally manage all fuzzing jobs

Easily review the failure history of

regenerating runs for multiple builds.

- Duplicates and Logging


Easily know what the run is and a general

overview of the results.

Failures are grouped and

categorized based on the Fuzzer’s

results.

Easily log or tag bugs for multiple failures in the run.

Failures can be hit across multiple

products.

Files collected can be restricted to a small set.

DFF will recommend bugs

for failures.Find out additional failure details including EIP, Fault

Address, Instructions, Registers, a complete call stack, repro files, dumps,

and OS version.

Bug icons helps the tester to know the status of the bug without loading Product Studio.

Teams Utilizing DFF today Office Windows SharePoint Services SWI/MSEC-React FAST Search MSN Client Expression Blend, Design, and Encoder

Results with DFF

• Aggressive about fixing issues. Exploitability not important if fixed.• Fixing some issues that aren’t security issues.

• Example: derefs when initialized to null.• Data was obtained 5/31/2010.

1900

600

225 250

1800

File Block and Gatekeeper

File Block Block unused file formats Easy policy enforcement

‘Gatekeeper’ Runs automatically on open Evaluates file for ‘correctness’ Protects against unknown

exploits Faster Updates

Reduce the

Attack Surface

Gatekeeper DemoMost MSRC cases reported from January 2007 – today are automatically detected

The Office ‘Protected Viewer’

Mitigate the

Exploits

Office Protected

Viewer

Files that failed

Gatekeeper

Files that don’t comply

with File Block Policy

Files in unsafe folders

Outlook attachments fromexternal senders

Files from the

Internet Zone

Protected View Architecture Architecture uses two app instances:

“Host” process Runs with full rights. Owns top level app window (window caption,

ribbon, etc.)

“Client” process Runs inside highly restrictive sandbox. Parses and renders document content. Owns a single child window (parented to host

window) that corresponds to document canvas.

Host Window

Client Window

Sandbox Components Restricted Token Job Object User Interface Privilege Isolation (UIPI)

Net Impact of Sandbox At a high level:

Can only write to places (e.g., disk, registry) that have been explicitly ACL’d to allow it

Can only read from places that Everyone can read from (e.g., can read from c:\windows, but not My Documents)

Net effect: Malware is mitigated against installing a root kit,

corrupting/deleting documents, compromising your profile, changing your settings, etc.

Key Protected View Benefits Key “last line of defense” for exploits

that: Make it past Gatekeeper validation And are not thwarted by NX, ASLR, GS, etc.

Allows us to build more seamless user experience by reducing prompt fatigue

Provides mitigation for Gatekeeper false positives

Inside Winword.exe The real guts of Word lives inside of

wwlib.dll. winword.exe calls into the dll. Wwlib decides if ProtectedView should

be used. If necessary wwlib creates a new

instance of winword.exe running in low integrity.

Broker Process

Sandbox Process

Process Explorer View:

Protected View Configurable

Read Zone.IdentifierTIF, shares, etc.Write Zone.Identifier

C:\Program Files\Microsoft Office\Office14>WINWORD.EXE /vp c:\MyDocs\test.doc

// Force open in Protected View (/vp)

C:\Program Files\Microsoft Office\Office14>WINWORD.EXE /vu c:\MyDocs\test.doc

// Force open without Protected View (/vu)

ProtectedView Architecture Demo

Improve User Experience

Better information to make trust decisions

Avoid forcing choice between security and productivity

Areas for improvement remainImprove

User Experien

ce

Office 2007 Prompts

Improve User Experience

‘My Stuff’...IncomingStrong protection from all classes of malware inside

sandbox.

Trust decisions are ‘sticky’View document before trust

decision is made. Many scenarios stop here – reading is enough.

Open email attachment

‘Gatekeeper’Validation

SandboxedViewer

User Clicks ‘Enable’

Document opens, fully

enabled

SaveDocument

ReopenDocument

MSRC Case Demo against Office 2010

Appreciate help…

Lots of improvements, but not perfect. External people also continue to

innovate. If you have crashing files you feel are

security issues, even if you can’t show they are exploitable, please send them to us ([email protected]).

We will investigate and credit you for the find.

mailto:[email protected]

Thanks…

Brad Albrecht Atin Bansil Brian Carver Rob Cooper David Heise Eric Jarvi Hidetake Jo David Leblanc

Vikas Malhotra Alan Myrvold David Seidman Jason Shirk Kumar

Srinivasamurthy Octavian Timofte

Questions?

tom gallagher – senior security test lead, office trustworthy computing david conger – software...

Documents

fuzzing jobs

fuzzing passes

bluehat fuzzing olympics

duplicate crashes

surface huge

logging crashes

multiple teams

formats different fuzzers