Updated Online Binary Planting Exposure Test

Yesterday Microsoft issued a security update for the Windows Address Book binary planting vulnerability, which was used in our Online Binary Planting Exposure Test. Since the launch of this online test, thousands of Windows users worldwide used it to check their exposure to Internet-based binary planting attacks, and we're happy to see people using it for testing their countermeasures.

Obviously, Microsoft's security update broke our online test. While it could still be used for verifying the effectiveness of this particular Microsoft's update, it could no longer serve its original purpose.

We thus extended our online test with two additional unfixed vulnerabilities, one for Windows XP and one for Windows Vista and Windows 7, which allow users to continue testing their computers for exposure to Internet-based binary planting attacks.

For Windows XP, we chose a publicly disclosed binary planting vulnerability in Program Manager Group Converter. Similarly to the now fixed Windows Address Book vulnerability, this one is triggered by double-clicking on a GRP file.

For Windows Vista and Windows 7, our online test exploits a binary planting vulnerability in Windows Media Player 11 and 12, triggered by opening an MPG file. Its exploitability in a real-world attack is limited: Windows Media Player correctly sets its current working directory to a safe location upon startup, therefore simply double-clicking an MPG file in Windows Explorer will not load the malicious DLL from the attacker's location. It is perfect for our test though, as all Windows Vista and Windows 7 systems have Windows Media Player installed, and our tests are not exploit demonstrations but rather a tool for determining one's exposure to a particular type of attack.

We welcome everyone to use our free online test for both verifying the effectiveness of Microsoft's security update and for determining whether it is possible for an external attacker to exploit binary planting vulnerabilities on your computers. Do the Online Binary Planting Exposure Test now!

The Unbearable Lightness Of Non-Fixing

A Short Study on Security Reactiveness And Proactiveness

Exactly 97 days after a new old vulnerability type called Binary Planting, DLL Hijacking, DLL Preloading and Insecure Library Loading has gained public attention, it is clear that:

1. These bugs are ubiquitous and can be found in many widely-used as well as less known applications;
2. Not just DLL loading, but also EXE loading is affected;
3. Remote exploitation of these bugs is not just possible but possible in a wide variety of ways, also from Internet servers directly to internal corporate networks (Stuxnet, for instance, uses binary planting); and finally:
4. Few vendors seem to care much about fixing these remote-execution bugs.

Let us substantiate the last claim and provide some thoughts about possible reasons for this situation.

We have two different sources of information on existing binary planting bugs and their status. The first source are published full-disclosure reports provided by many researchers. We chose Secunia's list of verified advisories as a representative sample of publicly known binary planting bugs, although many researchers worldwide are doing a great job in finding these bugs. The second source is our own private list of publicly unknown binary planting vulnerabilities, which we've built throughout our Binary Planting Research Project. We're only using a subset of the vulnerabilities we found in this project: we re-tested some of the most widely-used products and omitted bugs subsequently found by others and publicly disclosed.

These two sources are both fairly large (compared to other similar sources), both verified and both providing vulnerabilities of the same type. The only important difference between them is that one provides publicly known vulnerabilities and the other vulnerabilities unknown to the public. This gives us a unique opportunity to get a peek into the - otherwise inaccessible - world of unknown vulnerabilities.



Status of PUBLICLY KNOWN binary planting vulnerabilities

	Total	Unfixed	Fixed	Percent Fixed
DLL Planting bugs	151	128	23	15%
EXE Planting bugs	8	1	7	88%
DLL+EXE Planting bugs	159	129	30	19%

The above table shows the status of those binary planting vulnerabilities that have been fully disclosed to public. Note that the amount of time elapsed since their disclosure is not taken into account; however, majority of these bugs have been disclosed at least 2 months ago. We assume (i.e., hope) that most affected applications' vendors are aware of the published vulnerabilities.

Out of 159 vulnerabilities verified by Secunia, 19% have been fixed so far. Interestingly, after some web browser vendors' initial quick response (Firefox, Opera, Safari), most of the fixes were done by smaller vendors, perhaps predominantly in open-source software. In general, large vendors seem to be very slow in patching - which is often rationalized by extensive testing they need to perform, but may also be due to their business models not providing sufficient rewards for security fixing. An unfixed known vulnerability in Windows Address Book, for instance, can still be used for testing your exposure to binary planting.

Status of PUBLICLY UNKNOWN binary planting vulnerabilities

	Total	Unfixed	Fixed	Percent Fixed
DLL Planting bugs	66	62	4	6%
EXE Planting bugs	28	28	0	0%
DLL+EXE Planting bugs	94	90	4	4%

The above table shows the status of binary planting vulnerabilities that have not been disclosed to public; these bugs have been discovered between December 2008 and July 2010 (but only a subset is being used here). It is unknown whether the affected applications' authors are aware of these vulnerabilities or not.

Unsurprisingly, very few of the publicly unknown vulnerabilities have been fixed, and of those 4 that have been, the affected products have mostly changed their design and appearance substantially, which might have led to accidental (as opposed to intentional) fixing.


Conclusions

What can we conclude from this? First, the status of publicly known binary planting bugs shows that vendors are slow at fixing these bugs even though their existence is obviously accessible to their customers, and also available to those who might want to attack the said customers. In a profoundly unscientific way we could say that today's software vendors' security reactiveness runs at 19%. If we ever hope to have our increasingly critical computer systems decently secure, vendors should strive to reach a 100% rate of prompt reaction to known vulnerabilities. Fixing a remotely exploitable critical bug in a few days should then be a norm, not an exception.

Second, the status of publicly unknown binary planting bugs provides a rare insight into software vendors' proactiveness when it comes to security. Remember that binary planting vulnerabilities have been all over the media for over three months, analyzed on many blogs and discussed in length on numerous web sites and forums. It is hard to imagine that a software vendor actually proactive in security (never mind what their marketing material says) could miss all this. And a proactive vendor would at least fire up Process Monitor and take a look at how their applications load libraries and launch executables. Accounting for the likelihood that the four fixed unpublished bugs were fixed by accident, we could say that software vendors' security proactiveness, as far as binary planting bugs go, runs near zero.

Finally, there's no reason to believe that binary planting bugs are getting treated any differently from other types of vulnerabilities. Similar results would probably be obtained from any sufficiently long lists of known and unknown vulnerabilities. Assuming that software vendors are behaving rationally and optimally with respect to their business objectives, the security of tomorrow's systems will require some adjustments to their business models. Bug bounties, recently offered by Mozilla, Google and some other vendors, just might be a step in the right (i.e., proactive) direction.

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.

Breaking The SetDllDirectory Protection Against Binary Planting

The curious case of Windows environment variables or how to re-hack fixed iTunes and Safari

If you're a Windows developer trying to protect your applications from binary planting attacks, you have probably heard of the SetDllDirectory function. This function removes the current working directory from the search path when  loading DLLs and allows you to replace it with a (hopefully safe) location you specify.

For instance, the DLL search order after calling SetDllDirectory("C:\SafePath\") becomes:

1. The directory from which the application loaded
2. C:\SafePath\ 
3. 32-bit System directory (Windows\System32)
4. 16-bit System directory (Windows\System)
5. Windows directory (Windows)
6. Directories in the PATH environment variable

When providing an empty string to SetDllDirectory, the current working directory is simply removed from the DLL search order:

1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Directories in the PATH environment variable

In theory, calling SetDllDirectory at the beginning of your code should solve the binary planting problem at least as far as loading DLLs go (reminder: EXEs are also affected). The concept sounds good and it is in fact one of the recommendations in our developer guidelines for preventing binary planting vulnerabilities.

In practice though, DLL-based binary planting attacks may still be possible. How? Enter the world of unexpanded environment variables, a known Windows bug that goes a long way in helping binary planting attackers.

Our researchers have (re)discovered a curious fact that some Windows environment variables sometimes don't get expanded in the PATH. For example, the CommonProgramFiles environment variable, which typically expands to "C:\Program Files\Common Files", sometimes simply remains %CommonProgramFiles% in the PATH. This bug affects many other environment variables on all Windows platforms and has not only been publicly discussed before since 2003 (see here, here, here, here and here) but Microsoft has also issued a KB article on the subject 3 years ago. The bug, however, was never fixed.

Now what does this mean for binary planting? Suppose an application calls SetDllDirectory to protect itself against DLL planting attacks. Obviously, the current working directory is no longer in its library search path - but the PATH still is! And if any one of the environment variables in the PATH remains unexpanded, well..., it becomes a relative path. That is, relative to the current working directory. For instance, if the PATH looks like this:

PATH=C:\Program Files\Java\jdk1.6.0_21\bin;
%CommonProgramFiles%\Microsoft Shared\Windows Live;
%SystemRoot%\system32;%SystemRoot%;
%SystemRoot%\System32\Wbem;
C:\Program Files\QuickTime\QTSystem\

and the CommonProgramFiles variable doesn't get expanded, the actual PATH included in the search path will contain the loaction

%CommonProgramFiles%\Microsoft Shared\Windows Live

In case the DLL hasn't been found in preceding locations in the search path, the application will at this point try to load it from a subdirectory of the current working directory, specifically from

CWD\%CommonProgramFiles%\Microsoft Shared\Windows Live

For illustration purposes let's take Apple's latest iTunes and Safari as examples (remember that their DLL and EXE planting bugs have already been fixed). These applications both call SetDllDirectory at the beginning of their execution, which is a secure coding practice that we recommend. Now let's assume you also have ActivePython installed. ActivePython adds %APPDATA%\Python\Scripts to the system PATH. There is nothing wrong with this! What is wrong is that APPDATA, due to the Windows bug described above, often remains unexpanded in PATH, which effectively makes iTunes, Safari and countless other applications vulnerable to binary planting attacks.

Let's see this in action.




Again, this is not Apple's fault (although they could improve their code by specifying full paths to their libraries) and it's certainly not ActivePython's fault (PATH is meant to be used this way).

Besides, it's not just the APPDATA variable that helps attackers in this way. Our Online binary planting exposure test's logs show Windows machines trying to load DLLs from various unexpected paths, including:

• %APPDATA%/Python/Scripts
• %ProgramFiles(x86)%
• %CommonProgramFiles%/Microsoft Shared/Windows Live
• %PROGRAMFILES(x86)%/Common Files/Microsoft Shared/Ink
• %USERPROFILE%/Local Settings/Temp
• %systemroot%/system32/DATA/Config
• %NpmLib%

What can we learn from this all? Mostly, don't just depend on SetDllDirectory to solve your DLL-planting problems. Use absolute, fully qualified paths to DLLs when loading them. Until Microsoft fixes this bug, any application that sets user or system PATH can unwittingly make your application vulnerable to binary planting if you're loading libraries from relative paths. And even then, some particularly adventurous application might add a relative location to PATH for whatever peculiar purpose, and break the SetDllDirectory  protection for the entire system. Again, use absolute paths to DLLs!

Finally, it needs to be said that this bug fortunately doesn't hinder the effectiveness of Microsoft's CWDIllegalInDllSearch hotfix. This hotfix successfully blocks DLL loads from the current working directory if configured properly even if relative locations are found in the PATH (it does nothing to prevent EXE planting attacks though).


Unexpanded variables bug analysis

For those interested in more information about the curious behavior of this Windows bug, here are some of our most important observations. We were testing on Windows XP Professional 32 bit, Windows Vista Business 32 and 64 bit and Windows 7 Professional 32 bit.

1.  We noticed that the "expandability" of certain environment variables sometimes changes by logging off or restarting the computer. For instance, APPDATA in the user PATH is initially unexpanded on Windows 7, but gets expanded after logoff or restart. On Windows XP, however, logoff makes this variable "expandable," but restarting the machine again makes it "nonexpandable".
2. Windows Vista 64 bit never expanded APPDATA in the user PATH, whatever we tried.
3. While Windows XP expanded APPDATA in system PATH at least after logoff, Windows Vista and Windows 7 never expanded APPDATA in system PATH.
4. COMMONPROGRAMFILES is never expanded in system PATH upon initial setting, and while other systems resolve this after logoff or restart, Windows Vista 64 bit never seems to expands this variable, period.
5. The same goes for PROGRAMFILES, which is a very common variable to use.

Many other environment variables are affected, making it relatively likely that the SetDllDirectory protection against binary planting will not be efficient on computers with multiple software products installed (which might add locations to user or system PATHs).

How Visual Studio Makes Your Applications Vulnerable to Binary Planting

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.]

HITB Preview: More Binary Planting Material Revealed

Re-Hacking Fixed iTunes and Creating a Binary Planting-Positive Application Without Writing a Single Line of Code

As the Hack In The Box conference in Kuala Lumpur is just around the corner, we'd like to announce a couple of previously undisclosed candies the attendees of our Remote Binary Planting – An Overlooked Vulnerability Affair session will receive.

Re-Hacking Fixed iTunes

As you may know, this binary planting bug in Apple iTunes is famous for triggering the whole DLL hijacking / binary planting / DLL preloading explosion that's been echoing around the Net for over a month now. We released the above advisory when Apple fixed the binary planting bug that allowed a remote attacker to get her malicious QUSEREX.DLL executed on users' computers. The vulnerable executable was AppleMobileDeviceHelper.exe (along with a number of others that also tried to load this DLL). Interestingly, iTunes.exe was already protected with a SetDllDirectory call, possibly as a result of the famous Safari-IE blended threat issue in 2008, where Safari and IE unwittingly colluded against users to execute malicious code on their computers.

Our analysis of the iTunes binary planting fix revealed that AppleMobileDeviceHelper.exe now calls SetDllDirectory as well, which is a good thing. In addition, it doesn't try to load the non-existing DLL any more, adding to the basic security hygiene. All is well in the land of apples and binary planting then, right?

Well... Come to our presentation at HITB and see what "blended threat" really means in this multi-player drama that will likely trigger some 2008 flashbacks. You'll learn that SetDllDirectory isn't always that effective, and see how iTunes.exe feels about it.


Creating a Binary Planting-Positive Application Without Writing a Single Line of Code

For those of you optimizing the number of keystrokes for writing vulnerable applications (we know you're out there), this will be your treat. We'll show how innocent, well-meaning developers can create a binary planting-positive application without  writing a single line of code, and without doing anything out of the ordinary. There is a well-known development platform out there that really takes the effort out of insecure coding. And chances are you're using it.

[Update October 18,2010: How Visual Studio Makes Your Applications Vulnerable to Binary Planting]
[Update October 27,2010: Breaking The SetDllDirectory Protection Against Binary Planting]

See you next week in KL!

Binary Planting Protection Guidelines for Developers

The Binary Planting web site is now providing guidelines for software developers who want to avoid introducing binary planting vulnerabilities in their products. These guidelines supplement Microsoft's guidelines.

Guidelines: http://www.binaryplanting.com/guidelinesDevelopers.htm

Opening a Can of Binary Planting Worms

Binary Planting as Worm Propagation Method 

Unsurprisingly, worm authors find binary planting a great method for their digital monsters to propagate from infected systems to new ones. Symantec's analysis of Stuxnet provides a good insight into one of this worm's methods for propagating among users of a particular software product, in this case Siemens SIMATIC STEP 7. Like many other mission-critical and expensive software products, SIMATIC STEP 7 has a binary planting vulnerability that loads a DLL from a data folder; if the DLL is there, it gets executed. This is a typical binary planting attack vector, and in this case also reveals the user population the worm is targeting.

Using binary planting for malware propagation is not new: in 2001, the infamous Nimda worm was planting riched20.dll alongside various Microsoft Office documents in an attempt to get it executed by other users when they opened these documents.

At the time of this writing there are 102 published and unfixed binary planting issues available for all worm authors out there to use. Add to these the 500+ binary planting issues we've discovered during our research (only a handful are published) and extrapolate the ubiquity of these flaws to all Windows software, and you'll get a feeling of the threat we're facing today. Right now, a worm that simply sprays malicious dwmapi.dlls all over the place should be very successful in its propagation, let alone a slightly more intelligent one that can map DLLs to document extensions and update its knowledge as new binary planting holes are found.

So are we entering an era of binary planting worms? Who knows? There certainly is no shortage of binary planting bugs nor is there likely to be one soon, and it is unreasonable to expect most Windows computers to have any protection against binary planting in place. On the other hand, worms will probably prefer the "double-click-bang" binary planting bugs to maximize their success-to-detection ratio, and many of these happen to be the relatively easy to find (and therefore more likely to get fixed).

I say "many of these" because in contrast to the binary planting issues published these days where a vulnerable application always loads a malicious DLL upon startup, we found many cases where  DLLs get loaded depending on various triggers, predominantly the content of data files. Worm authors may therefore decide to focus on such "triggered" binary planting issues which are more difficult to find but have a longer life expectancy. Undoubtedly, vulnerability black markets will be happy to accommodate such vulnerabilities for those who wish to focus on writing malware and leave vulnerability research to others.

Then again, worms don't particularly care about the types of vulnerabilities they use for propagation, as long as they get the job done quietly and efficiently. Perhaps, therefore, it is most likely that tomorrow's worms will simply add unpublished binary planting issues to their arsenal, along with buffer overflows and other types of remote execution methods.

As always, it is again up to software vendors to decide how much ammunition they want to make available to the malware authors. As it is again up to users to tolerate it or not.

Binary Planting Attack Vectors

There's more than one way to skin a cat... or plant a binary, for that matter.

There seem to be differing views among IT professionals on how easy or difficult it is to actually mount a binary planting attack. Microsoft's Jerry Bryant, for instance, was quoted saying: "Due to the fact that customers need to click through a series of warnings and dialogs to open a malicious file, we rate most of these vulnerabilities as Important," possibly referring to this attack example. On the other hand, Aviv Raff prepared a demo page for exploiting the (now fixed) uTorrent binary planting bug via Google Chrome (see video), showing how users can be tricked into a binary planting trap without any warnings. Attacks using USB tokens and CD/DVD media were discussed (which are quite feasible), and many researchers are convinced that binary planting attacks are fairly easy to mount. Our own experience in penetration testing confirms binary planting to be currently one of the most efficient and reliable methods for obtaining remote access to workstations in target networks.

Our team has done an analysis of many different delivery methods for binary planting attacks, providing a hopefully more comprehensive view on the feasibility of such attacks. We looked at some of the most popular web browsers, most popular e-mail clients and most popular document readers, trying to use them as delivery mechanisms for binary planting attacks.

Both Microsoft's and Raff's scenarios are included in the analysis along with many others. We've also provided a couple of demonstrations that you can test for yourselves and see how/if they're working for you. (Combine these with our online binary planting test to demonstrate the issue to your customers and friends.)

Some interesting findings:

• Clicking a link to a remote shared folder on a web page will open this share in Windows Explorer without a warning for 67% of all Internet Explorer users.
• Clicking a link to a remote shared folder in an e-mail message will open this share in Windows Explorer without a warning for all Outlook, Windows Mail and Windows Live Mail users, regardless of their default web browser. (E-mail is the most likely vector for targeted attacks on corporate and government networks.) 
• In contrast to Internet Explorer, we found no way to launch Windows Explorer via a hyperlink from Firefox, Chrome or Opera, while Safari does open a remote shared folder when the web page containing the link comes from a local drive (e.g., attacker sends an HTML file to the user via e-mail.)
• The Protected View makes Word 2010 and Excel 2010 less suitable for binary planting attacks, as documents originating from Internet or received via Outlook require the user to confirm a security warning before hyperlinks are enabled. 

All in all, it appears that most  attack scenarios don't include any security warnings. Users should therefore be careful when opening any hyperlinks - not just on web pages, but also in e-mail, documents and IM messages.  

See the Binary Planting: Attack Vectors analysis and find out how you can be attacked.

Binary Planting Goes "EXE"

Yesterday, Apple issued new versions of the Safari browser that fix a binary planting vulnerability our company has reported to them in March this year under our then-effective disclosure policy. (See Apple's and our own advisory.)

In the last 20 days since the binary planting monster escaped to the wilderness, eager bug-hunters were focused on unsafe loading of libraries, and understandably so: free tools were made available, and instructions were published on how to use monitoring software like Sysinternals' Process Monitor for detecting unsafe library loadings. As it turned out, tools + instructions + 20 days = 117 remotely exploitable vulnerabilities (at the time of this writing). The list is growing and will likely surpass our own list of 396 DLL planting and 127 EXE planting vulnerabilities at some time.

As we've already hinted, the search path problem does not only affect DLLs, or more accurately, LoadLibrary* functions. Indeed, this problem also affects the way Windows processes are launched via various functions such as CreateProcess*, ShellExecute*, WinExec, LoadModule, _spawn*p* and _exec*p*. (Asterisks denote various characters to avoid listing too many function names.) And if you thought the library-loading search path was dangerous, you'll probably be surprised about the (less documented) search paths for loading executables.

Let's revise the library-loading search path, as used by the LoadLibrary* functions.

LoadLibrary* search path

1. The directory from which the application loaded
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Current working directory
6. Directories in the PATH environment variable

It is obvious from this search path that a binary planting vulnerability can only occur when the requested library - specified without a path - is not found in the first four locations. This means, and our research confirms it, that most DLL planting issues will result from trying to load a library that doesn't even exist on the system (with a few exceptions). This nicely explains what we dubbed the "dwmapi.dll phenomenon": many Windows applications written for both XP and Vista/7 execute LoadLibrary("dwmapi.dll") to see if Vista Desktop Window Manager API is available. While on Vista/7 this DLL is found in system directories, it isn't on XP, leading to dwmapi.dll being loaded from the current working directory. Interestingly, our research has also found opposite cases where an application is only vulnerable on Vista or 7, but not on XP or older Windows systems.

Now let's look at the various search paths Windows are using for launching executables. In contrast to the LoadLibrary* search path, many of these aren't officially documented but can easily be observed with a file/process monitor.


CreateProcess*, WinExec and LoadModule search paths

1. The directory from which the application loaded
2. Current working directory
3. 32-bit System directory (Windows\System32)
4. 16-bit System directory (Windows\System)
5. Windows directory (Windows)
6. Directories in the PATH environment variable

This search path is identical to the old search path used by LoadLibrary* functions before the "safe search order" was introduced years ago. Apparently the current working directory is in the second place, which means that when an application tries to launch the Windows Calculator by calling something like CreateProcess(NULL,"calc.exe",...), a malicious calc.exe lurking in the current working directory will get launched instead. And remotely, too, if the current working directory happens to point to a remote network share in a local network or on Internet. And no, launching remote executables using these functions will never issue any security warnings to the user, in contrast to ShellExecute*. As far as we know, introducing ShellExecute-like security warnings to these functions would cause serious problems with various batch jobs and server back-end operations running without humans present.

ShellExecute* search path

1. Current working directory
2. 32-bit System directory (Windows\System32)
3. 16-bit System directory (Windows\System)
4. Windows directory (Windows)
5. Directories in the PATH environment variable
6. Directories specified in the App Paths registry key

Now this search path could not be friendlier to your binary planting attacker: the current working directory, possibly under attacker's control, is the first location consulted for the executable launched via a ShellExecute(NULL,"open","cmd.exe", ...) call. Fortunately though, Windows will issue a security warning when launching an executable from the Internet zone (but not from Local Intranet and My Computer zones). So for those of you who believe that users won't okay such warning the second time around after seeing that canceling it the first time failed to get them where they wanted to go, feel free to consider the ShellExecute binary planting vector intranet- and local-only.

_spawn*p* and _exec*p* search paths

1. Current working directory
2. 32-bit System directory (Windows\System32)
3. Windows directory (Windows)
4. Directories in the PATH environment variable

These functions, while probably used less frequently than CreateProcess* or ShellExecute*, provide a powerful binary planting potential: Trying to launch Notepad by calling _execlp("notepad.exe","r") will result in executing a malicious notepad.exe waiting in the current working directory, without a security warning under any circumstances.

There are many other ways to launch new processes in Windows, but most are likely to be wrappers for CreateProcess* or ShellExecute* functions, making their binary planting potential equal to that of their "wrapees".

So what have we learned today? First, binary planting is as much a problem with EXEs as it is with DLLs. Second, while DLL planting usually requires the DLL to be absent from the system, EXE planting works nicely with existing executables in system directories. And third, an application can be vulnerable depending on the version of Windows it is running on. Now make sure to test your applications on different Windows systems and update your Process Monitor filters to look for executables being loaded from the current working directory.

Are there any systemic countermeasures you can apply against EXE planting? Unfortunately not as many as for DLL planting:

• Microsoft's CWDIllegalInDllSearch hotfix only blocks the current working directory in LoadLibrary* calls, so it can't protect you or your applications from EXE planting attacks. According to this guidance, "Microsoft recommends that developers be careful when loading binaries and specify the fully qualified path name. This should pose less complexity when loading a binary as opposed to a library."
• The SetDllDirectory function also only affects LoadLibrary* calls. There is no SetExeDirectory function available at this time to change the search path of CreateProcess, ShellExecute and other process-launching functions.
• Changing the current working directory to some safe location either at the beginning of the application's execution or before loading libraries and launching processes can limit the exploitability of both DLL and EXE planting vulnerabilities. (However, applications tend to change their current working directory even if the developer had no intention for them to do so; but more about this in another blog post.)

P.S.: And don't forget to test your computer for exposure to binary planting attacks with our Online Binary Planting Exposure Test.

Online Binary Planting Exposure Test

ACROS Security has prepared a free public Online Binary Planting Exposure Test for all corporate and home Windows users who wish to test their exposure to binary planting attacks originating from the Internet. We'll try to keep a working demo of at least one unpatched, publicly disclosed vulnerability here for as long as there are any available.

This test is not an attack demonstration but rather a way for users to determine whether they could be successfully attacked from the Internet. While this test's failure to get the remote code executed on your computer does not constitute a proof of your security, its successful execution certainly proves your exposure and should prompt you to implement some countermeasures.

In particular, this online test can be useful for testing your binary planting countermeasures: Try the test with and without your firewall, test the effectiveness of your settings provided by Microsoft's CWDIllegalInDllSearch hotfix, or see if your anti-virus product protects you from the threat.

It is our goal to raise awareness of the binary planting problem among users, network administrators and developers. We hope this online test will help them understand the problem, test their exposure and fix their applications sooner rather than too late.

Test your computer now: Online Binary Planting Exposure Test

Clearing up Some Misconceptions About Binary Planting

As much is being asked, reported and experimented about the binary planting bugs in all corners of the Net, we're noticing some misconceptions and misunderstandings flying around. In hope to set some of these straight, here are some explanations:

Misconception #1: CWD-Addiction Implies Vulnerability

If an application exhibits problems because of Microsoft's CWDIllegalInDllSearch hotfix, it doesn't mean that it is vulnerable to binary planting attacks. This most likely means that the application is relying on the CWD (current working directory) being in the search path - which is a Microsoft-documented "feature" -, and is setting the CWD to the location where the needed DLL actually exists (often some folder in the application's home directory) before calling LoadLibrary. Since the CWD is not set to an attacker-controlled location, this provides no attack potential. An example of such false positive is this Google Chrome report; Chrome sets the CWD to one of its own application directories before calling LoadLibrary

Misconception #2: Application Loading a DLL From Home Directory Is Vulnerable

An application's running a malicious DLL from its home directory (i.e., where the application's main executable resides), is not an indication of vulnerability to binary planting. The search path for loading DLLs starts with the application's home directory and it is normal (and desired) that the application loads DLLs from there. Unless the application's home directory has bad access permissions that allow a low-privileged user to plant such DLL there in order to get it executed later by another user who launches the application, there is no valid attack potential here. (After all, a local administrator can always replace any executable or DLL.) An example of such false positive seems to be this AutoCad report. (Disclaimer: we haven't tested this AutoCad report.

Misconception #3: The Power Of SafeDllSearchMode

We've seen claims that in order for an application to be vulnerable to binary planting, it must first disable the SafeDllSearchMode, thereby upgrading the CWD to the 2nd place in the search path. This is incorrect. While disabling the SafeDllSearchMode would certainly render even more applications vulnerable, the hundreds of applications we found to be vulnerable to binary planting - as well as those being publicly disclosed daily in various exploit lists - are loading their DLLs in the "safe search mode." Since most of the binary planting vulnerabilities seem to be due to applications loading non-existing DLLs, it really doesn't matter whether CWD is in 2nd or in 5th place in the search path.

Misconception #4: The Power Of SetDllDirectory 

Simply calling SetDllDirectory at the beginning of an application is not a magical solution that completely does away with the problem. Even assuming that this call causes no functional problems in the application or any external code it loads and executes, there are many cases of binary planting that this setting doesn't affect.

Misconception #5: The Power Of CWDIllegalInDllSearch Hotfix

Similarly, Microsoft's CWDIllegalInDllSearch hotfix only addresses a subset of all binary planting issues our research has uncovered. We're planning on publishing further details on this next week. [Update: read this for further information.]

Releasing SHA-256 Hashes of Binary Planting Vulnerabilities

We're releasing SHA-256 hashes of 396 DLL planting and 127 EXE planting vulnerabilities we found during our extensive binary planting research. After a long internal discussion we decided that - considering the public availability of detection tools and instructions that make it possible for everyone to search for (a subset of) binary planting issues - it would not be appropriate to publish such information. We feel that doing so might encourage attacks against the identified vulnerable applications, which could negatively impact the security of end-users.

Hashes are available here: http://www.acrossecurity.com/files/binary_planting_sha256.txt

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.

Binary Planting Update, Day 6

As some of you may have noticed, the world of Windows applications is looking at some bumpy times. Six days ago, our company ACROS Security has published an iTunes security advisory, describing what we called a remote "Binary Planting" vulnerability. This vulnerability allows a remote attacker to place a (preferably hidden) malicious DLL on a network shared folder alongside a media file, and when users open this media file, the DLL will get silently loaded and executed by iTunes. We also published two similar vulnerabilities in VMware Tools in April. Which is all nice in and of itself, speaking as a researcher.

However, there's more jewelery stored in this particular chest. Our company has been conducting an in-depth research on this type of vulnerabilities since November 2008. We first developed a tool for detecting these bugs and then, time permitting, subjected about 220 widely-used applications to the powers of our tool. Initially expecting only a few bugs here and there, we were surprised to find about 90% of the applications vulnerable. And when I say "vulnerable", I mean vulnerable to remote execution in a real-world scenario, without having any privileges on the user's computer. In December 2009, we applied for a patent on many different methods for detecting this type of vulnerability.

Earlier this year, we informed Microsoft about our research, which allowed them to prepare for the publication and possibly provide some solutions for the affected users. And judging from our research results, there will be quite many affected users - we can safely say that all Windows users can at this moment be attacked via at least one remote binary planting vulnerability.

Now, unsurprisingly, we were not the only ones researching this area. Hours after our publication of the iTunes advisory, our respected peer HD Moore disclosed the existence of about 40 so vulnerable apps that he found. While we weren't planning on releasing our research until the end of August, HD accurately Tweeted that "the cat was out of the bag", so it was time for us to disclose some information as well. Which produced news articles here, here and here, among others.

Today, academic researcher Taeho Kwon also joined the party with the research paper he and Zhendong Su have published earlier this year. Their paper mentioned a couple of vulnerabilities of the "remote binary planting" type, i.e., where the malicious binary is loaded from the current working directory, allowing for a remote, even Internet-based attack. In the above article, Kwon claimed to be in possession of 19 remotely exploitable vulnerabilities, and there's no reason not to believe it because they have proven their ability to find them. However, it would be wrong to think that over 1,700 "unsafe DLL loadings" mentioned in their paper allow for remote exploitation - in fact, most of them seem to require local administrative privileges for exploitation. That said, Kwon and Su have done a great job and a very thorough research, and can prove to be an important source of concrete Binary Planting vulnerability information in the weeks (months) to come.

Finally, why do we call it "Binary Planting" if it's an old bug that's already been named "DLL preloading", "Unsafe library path", "DLL spoofing" or, to some extent, "Vulnerable dynamic component loading"? The main shortcoming of these names is the fact that the same problem affects not only the libraries but also executables such as .EXE and .COM files. Our upcoming research paper will provide more details and will hopefully justify the new name.