Analysis Of The Microsoft Office 2010 Binary Planting Bugs

Keeping binary planting bugs out of 120 million lines of code

In the course of the ongoing binary planting research, our company has discovered five binary planting bugs in Microsoft Office 2010: two in Word 2010, one in PowerPoint 2010 and one in Excel 2010. We notified Microsoft about the PowerPoint bug on July 20th (about 110 days ago), but subsequently this bug was also found and published by other researchers.

Yesterday Microsoft released security updates for Microsoft Office 2010 (here, here) resolving this issue. They acknowledged our researcher for the find, and, not unimportantly, seemed to have upgraded the severity rating to "critical" (from their original assessment of binary planting bugs as "important"). In light of our current research, where we're already able to exploit binary planting bugs with as little user assistance as visiting a web page and clicking twice in arbitrary locations, the highest severity rating would be quite appropriate.

Microsoft didn't just fix the PowerPoint binary planting bug we reported; they also fixed two other binary planting issues we knew about in Word 2010 and Excel 2010 (although you won't find these mentioned in their bulletin). Since these are the first binary planting bugs fixed by Microsoft, they deserve a bit of attention. Let's start with some technical details:

The three binary planting issues all had a common source: the library called mso.dll (installed in %ProgramFiles%\Common Files\Microsoft Shared\office14\). This library made an unsafe call to LoadLibrary("pptimpconv.dll") in PowerPoint, LoadLibrary("wdimpconv.dll") in Word and LoadLibrary("xlimpconv.dll") in Excel. These DLLs, however, did not exist on Windows computers, and were thus loaded from the current working directory. The exploitation of such bugs is simple: place an Office file alongside a malicious DLL with the right name somewhere where the user will be able to access it (e.g., DVD, USB key, local drive, local share or remote WebDAV share), and get the user to open the document. For the PowerPoint bug this was it; for Word and Excel however, the Office Protected View, if it decided to kick in, actually provided an additional layer of security as these DLLs were only loaded if the user decided to enable editing by clicking the button in the message bar.

For all three bugs, it was a case of a "classic" binary planting error of a most common type: trying to load a DLL to see if it's there. Google search seems to find nothing about these DLLs outside the binary planting context, so we conclude that this was likely a case of "forward compatibility," i.e., Office applications trying to load DLLs that were planned to be placed on the computer at some point in the future.

Yesterday's security update fixes these bugs such that the non-existing libraries are not being loaded any more.

From the development perspective, one might wonder how difficult it is for a vendor to find all binary planting issues in their own code, or, better yet, to prevent them from being introduced in the first place. It seems really easy: search the entire source code for LoadLibrary calls and make sure they all provide a full path to the DLL, or that the DLLs they load are sure to be found in the application folder or one of the system folders.

But it isn't easy. The millions of lines of Office code probably contain tens of thousands of LoadLibrary calls, many of which don't use string literals for DLL names but some input passed by a calling function. Furthermore, many of these calls, even if potentially vulnerable, may not be exploitable (so it wouldn't make economic sense to invest into additional coding and testing), but it can also be very time-consuming to determine which are exploitable and which aren't. No vendor will invest a lot of effort into something that may not even be a problem.

And it's not just LoadLibrary calls: all functions/methods in all languages (including macros, VBScripts, JScripts and shell scripts) that load libraries or launch executables can be a source of binary planting bugs.

The mighty proactive SDL (secure development lifecycle) apparently doesn't help much either, or there wouldn't be so many binary planting bugs in so many products by so many vendors practicing it. Training developers in secure coding sounds nice, and it surely contributes to the security of software products, but if it fails to eliminate trivial bugs like binary planting (and buffer overflows, and cross-site scripting, and what-not-injections), perhaps it is time to rethink the priorities.

With today's complex software products, security requires more control. Much more control. Even if developed by super-trained security paranoids, applications need more external security testing, more hacking from different directions, more proactive "attacks" by people with different experiences and knowledge. All that before they get installed on users' computers, if we want to call our approach to security "proactive" in any meaningful way.

P.S.: As for the two aforementioned unfixed binary planting bugs in Office 2010 and further news on binary planting, follow our research on Twitter.