Security is a critical component in all our products at Microsoft. An emphasis on strong security starts at the beginning of all our work, including threat modelling as part of the design process and the consideration of Apple’s own security recommendations for our products on Apple’s platforms. As an example of this approach, I’d like to share some of the work we’re doing to help secure Mac Office 2016.
For Mac Office 2016 and the Office 365 subscription system, we keep our tooling system “evergreen”. With Mac Office 2016, we ship an update every month and test and adopt the latest versions of Xcode and its internal tools as they are released. We mitigate the risks of compiler changes with extensive automated testing. We have a farm of hundreds of Mac Minis that run tens of thousands of scenario-based tests every day, and we investigate every failure or unexpected behavior change that the automation system reports.
We augment our automated scenario testing with static analysis of our code wherever possible, and we include input fuzzing with intentionally corrupted files and data to identify improper expectations in our code. Across all of Office we are investing in ever-more-intelligent fuzzing tools and running them on a continuous basis. This drives better data validation, particularly in older code, and makes applications more stable and secure.
By using the latest toolchain we get the security benefits from compiler improvements. These updates constantly bring new code warnings; we enable them all by default and treat warnings as errors. This improves our code quality with every new compiler release. Not all compiler warnings imply a security problem, but those that do trigger errors that we work to fix immediately. We also look for new optional compiler security features (such as -fstack-protector and -D_FORTIFY_SOURCE=2) in each release and turn them on. The toolchain updates bring new macOS and iOS SDKs with annotations for new APIs as well as deprecated or insecure APIs in the OS. We take those annotations seriously and update our code to remove the use of the latter.
Xcode 7 introduced a new tool called the Address Sanitizer (ASan). This tool can help identify bugs with potential security ramifications, however it requires more memory than a non-ASan build and isn’t practical for large 32-bit applications. Mac Office 2016 is now 64-bit, and we produce an internal ASan-instrumented build daily and run it through the same automation tests as the regular product. Any ASan issue that the automation system discovers becomes a bug report to be investigated and resolved.
We also make security improvements beyond code changes forced by the new toolchain or by the 64-bit transition. We re-engineered the Office suite to use restricted executable memory pages only where necessary and we maintain a blacklist of APIs that are considered inherently insecure or that allow insecure coding practices. We routinely audit the codebase to ensure that none of these APIs are used. We also build our applications with Position-Independent Execution enabled. With that flag, with our minimum supported OS of 10.10, and the fact that all our Office applications for Mac are now 64-bit, the macOS can apply Address Space Layout Randomization to our apps as another layer of defense.
Although it is optional for macOS applications, we also turn on the macOS sandbox for our applications. Opting into the sandbox adds yet another roadblock for nearly every threat we evaluate, making exploits more difficult. We consider this a best practice for Mac applications. The sandbox changes how the applications interact with the OS, requiring us to revisit several existing Office features to make them sandbox-compliant and still leverage the capabilities of the full Office suite.
These security improvements apply to the latest versions of our applications. Our automatic update tool itself benefits from almost every improvement listed above. Every update package is signed by Microsoft and that signature is verified every time a package is downloaded. We are routinely improving the user experience to reduce the effort to install updates and make it an invisible action that completes automatically. This encourages our users to always have the most secure application version installed.
Putting all these changes together makes Office 2016 for the Mac our most secure version yet. We turn on stricter compiler security features at compile time, we build and link expecting ASLR to locate us randomly in memory at boot, we audit for insecure APIs and ban them from the codebase, we fuzz input to verify data parsing, we disallow heap-execution, we opt into the macOS sandbox, we look for possible security flaws at runtime with the Address Sanitizer, and we make it more likely for users to have the latest security updates. All of this places a very tall set of hurdles in front of possibly-nefarious code, helping to protect your applications, your data, and your Mac.
Erik Schwiebert, Principal Software Engineer, Office for Mac