What Office 2010 Can Teach Us About Security

I continue to be impressed with the changes coming in Office 2010 (currently in beta). Previously, I explained how Microsoft drew on real-world usage data to craft the beta suite's updated UI. Security is another priority for the upcoming release, and while the improvements there aren't as readily apparent, for developers they're equally noteworthy.

The Office suite is complex and feature-rich, making it a ripe target for malware and other security exploits. Given its vast and diverse user base, however, for Microsoft to remove existing features in the name of security would be out of the question.

Instead, the Office 2010 product team concentrated on developing a new security strategy. It studied past vulnerabilities to learn how they were exploited and what could be done to prevent similar abuses in the future. The result was a new, multilayered security model based on five essential principles -- ones any application developer would be wise to remember:

1. Validate all user input before acting upon it
Any good programmer knows input validation is crucial. Unverified input can lead to buffer overruns, code injection attacks, and any number of other software flaws. But too often coders think only of validating form fields, text input boxes, and other UI elements. What about documents?

One way Office 2010 avoids unwanted security surprises is by prevalidating documents against a library of schemas of documents with known qualities -- good and bad. The idea is that Office will be able to recognize specific document types and engage proactive security measures before it starts to interpret their code -- for example, by disabling macros when it encounters documents that match the characteristics of known Word macro viruses.

2. Look for random flaws and atypical use cases
Well-crafted use cases are crucial to software testing, but not even the wiliest of QA engineers can think of everything. The nastiest bugs can arise from unexpected areas -- and sometimes all it takes is a few unexpected bytes to trigger them.

That's why the Office team uses a technique called "file fuzzing" to detect unanticipated use scenarios. Fuzzing takes documents that are known to be valid and changes them at random -- for example, by swapping parameters around, changing the contents of fields, or simply introducing random garbage data into the middle of the file.

Ideally, applications should be able to handle fuzzed files gracefully. In the worst-case scenario, however, opening a fuzzed file leads to a crash -- and that's a red flag for a possible security exploit. According to Microsoft reps, the Office 2010 beta can successfully handle fuzzed files 10 times more often than Office 2007.

Subscribe to the Security Watch Newsletter

Comments