Microsoft Exploitability Index Changes

Microsoft is making changes to its exploitability index to help clarify vulnerability issues in its software to its customers, keeping its program far ahead of other major vendors. Still, no system is perfect.

Microsoft’s Security Response Center team has a steep uphill climb to conquer the mountain of vulnerability handling in their software that slowly but surely are publicly discovered, exploited and discussed. It is not an enviable task.

In just five days, the team will roll out a couple of changes. One change splits exploitability ratings for their newest product versions from all older releases. The two updates for the upcoming Patch Tuesday will also provide information for the bugs even if they do not provide remote code execution, and instead provide a surface for denial of service attacks.

This index is aimed at more technically minded individuals and organizations to help evaluate the urgency of installing available patches or shielding yet unpatched vulnerable applications and services. So, these changes are really used by larger organizations with technical staff than individual consumers. For consumers, generally the guidance is to auto-update and install the patches as soon as they are released. Microsoft has a massive, rigorous QA process for security patch compatibility and rollout issues, so that problems for individual consumers are minimized while lowering overall security risk. The first of the changes inevitably will quantify the benefit for organizations and consumers to maintain the latest versions of Microsoft products.

But consistently accurate evaluation of the exploitability of these bugs is something that has come into question by researchers over the past couple years, and more recently by Ryan Smith and Chis Valasek at Infiltrate 2011. The two dug into the recent MS FTP server heap overflow declared “unexploitable” by the Microsoft team and demonstrated complicated techniques to obtain eip. Admitting that their approach may have some limitations in the real world, the work nonetheless brought into question the assumptions and vagaries that may go into an exploitability index like this one. So the second of the changes, and the usefulness of the index overall, is somewhat thrown into question. Can a single team really provide enough insight into the code?

Still, the amount of effort and interest that Microsoft has put into its secure coding and vulnerability handling efforts puts its process years ahead of other major software vendors. To see Adobe, Oracle and Apple make solid, comparable advances in their vulnerability programs would make the net a much safer place. Please, join the party!