Creating a Binary Planting-Positive Application Without Writing a Single Line of Code
As attendees of the Hack In The Box conference learned last week, Microsoft Visual Studio makes it possible to develop a binary planting-positive (i.e., vulnerable) application without you having to write a single line of code in just 34 seconds. Let's look at the video first.
The video shows the process of creating an empty default MFC application (the Project Style setting could have been left at "Visual Studio", but "MFC Standard" creates an even simpler application) and associating this application with a ".bp" file extension ("bp" as in "binary planting", of course). Double-clicking test.bp then lunches the application and loads a malicious dwmapi.dll from the same directory.
At this moment (October 18, 2010), every single MFC application built with either old or updated Microsoft Visual Studio 2010 (probably others too) tries to blindly load dwmapi.dll upon initialization, resulting in a binary planting vulnerability when executed on Windows XP or older Windows systems (affecting more than two thirds of all Windows users). There is nothing a developer can do to prevent this; there are no settings in Visual Studio to change this behavior of MFC applications. The vulnerability lies in Microsoft's MFC library which comes with Visual Studio and is distributed to users' computers as part of Visual C++ Redistributable Package.
A number of applications have already been publicly reported vulnerable due to Microsoft's MFC library, including TortoiseSVN, L0phtCrack, BS Contact, Artlantis Studio, ALShow, DVDFab, ALZip; our own binary planting research project has identified a dozen more.
There is a mitigation factor though: if your MFC application is not associated with a file extension (i.e., it can't be launched by double-clicking on a file) and is not meant to be launched from the command line interpreter, it will be difficult to exploit.
There's good news and bad news for the developers. Good news is that only MFC applications seem to be affected. Another good news is that when Microsoft decides to patch the Visual C++ Redistributable Package, many of the affected applications should be automatically fixed on users' computers.
Bad news, however, is that this only applies to MFC applications that dynamically link MFC libraries; if these libraries are linked statically, they get integrated in the application's executables and do not use the redistributable libraries that Microsoft can patch on users' computers. Developers of such applications will have to wait for Microsoft to patch the bug in Visual Studio, rebuild their applications in order to integrate the fixed MFC code, redo the test runs, and deliver the new builds to every one of their users. In absence of automatic update facilities, these vulnerable applications are likely to remain so for a long time.
[Update April 13, 2011: Microsoft provided security updates for both Visual Studio and Visual C++ redistributable packages. See our blog post for more details.]
