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

2.  History of Office Security  Our approach to securing Office  Demos of internal tools and protections in Office 2010.

3.  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).

7.  SDL Compliant  OACR (Automated Code Review Tool)  SafeInt  Remove old parsers  Intensive Distributed Fuzzing

8.  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.

10.  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

11.  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.)

12.  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..

13.  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..

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

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

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

17.  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.

18. Hundreds of Fuzzer configurations across many different types of fuzzers are available.

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

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

21.  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.

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

24. Easily review the failure history of regenerating runs for multiple builds.

25.  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.

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

29.  Office  Windows SharePoint Services  SWI/MSEC-React  FAST Search  MSN Client  Expression Blend, Design, and Encoder

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

31.  File Block  Block unused file formats  Easy policy enforcement  ‘Gatekeeper’  Runs automatically on open  Evaluates file for ‘correctness’  Protects against unknown exploits  Faster Updates

32. Most MSRC cases reported from January 2007 – today are automatically detected

33. 

34.  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.

36. Host Window

37. Client Window

38.  Restricted Token  Job Object  User Interface Privilege Isolation (UIPI)

39.  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.

40.  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

41.  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:

42. Read Zone.Identifier TIF, 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)

44.  Better information to make trust decisions  Avoid forcing choice between security and productivity  Areas for improvement remain

46. ‘My Stuff’... Incoming Strong 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.

48.  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 (secure@microsoft.com).secure@microsoft.com  We will investigate and credit you for the find.

49.  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