Binary Planting Update, Day 7

Yesterday, Microsoft officially responded to the Binary Planting issues discussed all over the web in the past few days. They published a number of documents (Advisory, SRD blog, MSRC blog and MSDN article on Dynamic-Link Library Security) and issued an update which introduces new functionality to Windows for mitigating Binary Planting attacks.

Now that these are out, let me present our story of collaboration with Microsoft. Perhaps you can learn something about the way things work in the background and draw your own conclusions.

First off, those of you looking for the typical vendor critique and Microsoft bashing: sorry, not this time. And for the record, Microsoft is not our customer, at least not in the paying sort of way.

Our research on Binary Planting came to a conclusion early this year by passing the 512-bugs target we've set at some point. During the research, we've been privately notifying our customers about bugs in their products and made it possible for them to fix them before the research would get published. At some point, though, it became clear that a publication of such a heavily populated class of remotely exploited vulnerabilities could easily cause a serious global security problem if billions of Windows users and organizations had no way to protect themselves - not just from the bugs we've found, but also from other bugs that some less law-abiding netizens would start discovering and exploiting.

On March 24, therefore, we contacted Microsoft and offered to present our research to them and start working on some solution or workaround that they could issue in a response to our planned publication. We included fully detailed bug reports for two of the 121 binary planting issues we'd thus far found in 41 Microsoft's applications.

Katie Moussouris and Maarten Van Horenbeeck, Microsoft's main security researcher coordinators, were quick to respond and a few days later, we had the first out of many long conference calls, walking through our slides and discussing both our findings and their options. It was obvious that Microsoft was not unaware of this problem (after all, they've been warning developers in many web articles for years) but they were genuinely surprised at its ubiquity and remote exploitability. It was immediately clear to them that something needs to be done and they asked us to give them time to prepare some solution not just for their vulnerable products, but for all applications running on Windows.

Since then, we've had countless late-afternoon/early-morning phone calls with Maarten and Katie, who really put their best effort, and a lot of it, into coordinating some of the brightest Microsoft security minds, including David LeBlanc, with our own knowledge in search of an optimal fix. It turned out there was no magical solution that Microsoft could dispatch to do away with binary planting in general, so the focus shifted to the best possible workaround. This meant, and still means today, that each vendor will have to fix their own products to completely eliminate the problem.

By mid July, Microsoft had prepared the mitigation which you can now get in their update and decided to delay its release until our research becomes public. Don't hold this against them though: it was in their customers' best interest to delay the delivery of the update because it would surely get reverse-engineered within hours, which would be roughly equivalent to disclosing the problem only to the bad guys. We, on the other hand, were planning on releasing our paper late August - but then our iTunes advisory let the "cat out of the bug", as HD Moore cutely mistyped on Twitter.

In parallel to the above, there was also a question of our providing the details of all 121 bugs in Microsoft's products to the Redmond giant. While we did give them a list of their vulnerable products (with versions), we declined to provide the details for free (this is our core business after all). However, there was no bad blood about it - Microsoft respects our desire to get compensated for providing such valuable data, and we respect their policy of not paying for vulnerability information. Also, Microsoft certainly has internal resources for doing their own bug-hunting once they know what to look for and where. So at the end of the day, this was a mere incompatibility of business interests, but the important thing is that it did not affect our fruitful collaboration on the more important issue - that of finding a cure for all users and all applications (not just Microsoft's).

In conclusion, we'd like to acknowledge Microsoft's Maarten and Katie for their really high-intensity involvement in this collaboration, but also the unnamed Microsoft engineers sweating in the background to provide the update available to users today. It isn't a perfect solution, but it should provide some protection until software vendors fix their products.