14 DAY TRIAL // Microsoft will not be releasing any security patches for Office 2010 this month. And the latest iteration of the Office suite being “ignored” for the May 2011 Patch Tuesday is somewhat of a trend, considering just how few security bulletins the software giant released to patch vulnerabilities in Office 2010 since GA last year. Office 2010 is but one example of the Redmond company’s Security Development Lifecycle code development best practices in action, and fuzz testing is one of the strategies employed to secure the product.
“The Office team used automated distributed file fuzz testing to identify bugs and potential application vulnerabilities during the development of Office 2010. In addition, we continue to test throughout our support lifecycle,” Microsoft’s Alistair S. said.
“As part of our testing efforts, millions of Office files, representing the entire spectrum of over 300 different file formats across the whole Office suite were fuzzed tens of millions of times each week in different ways to try and identify new vulnerabilities in all file formats Microsoft Office opens.”
The Office 2010 suite received accolades earlier this year from security researchers Dan Kaminsky and Will Dormann which both performed independent fuzz testing on the solution.
What they found was a very small number of crashes, and concluded that an even smaller number of those were exploitable or potentially exploitable.
Notably, Kaminsky and Dormann independently revealed that Office 2010 is less prone to successful exploits than open source rival StarOffice, the successor of OpenOffice.
“File fuzzing is the process of modifying file formats by feeding random data or “fuzz” into an application and then monitoring how the application responds to the data,” Alistair explained.
“This testing procedure is performed both by companies creating software and by attackers developing malware. Companies creating software use the technique to find bugs or problems within their software application and to then help ensure that the application is as secure and stable as possible before making it available to the public.
“On the other hand, attackers developing malware use file fuzzing or file format attacks to attempt to find and then exploit vulnerability within the application. Once vulnerability is found, the attacker can create a targeted file format attack to try and exploit the vulnerability within the software application.”
Personally, I don’t believe that the volume of vulnerabilities, including potentially exploitable crashes, is a direct measure of software security.
However, it’s my opinion that the reduced number of vulnerabilities/crashes is a reflection of the quality of the code, which in its turn guarantees superior security, since the number of critical issues that could enable exploits is reduced.
It’s critical to note that code can never be perfect, so additional security measures are required to make vulnerabilities, if they exist, extremely hard to exploit.
Such measures are dubbed security mitigations, and there are plenty of those in Office 2010, including Protected View, file block settings, Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) and File Validation.