Hey, it's Will. Earlier this year, details about "carpet bombing" attacks were released. Apple addressed the issue by prompting users before downloading files, but recent news indicates that Google Chrome, which is based on Apple's WebKit code, is also vulnerable to the same type of attack. However, some people seem to be missing an aspect of the attack that affects all web browsers.

When loading a DLL, Microsoft Windows looks for the DLL in a certain sequence of directories. The first match for the file name wins. In most cases, Windows will first look for a DLL in the same location as the executable. This behavior is what allows the Apple Safari "carpet bombing" vulnerability to work. If an attacker can place code in a directory that gets searched before Windows finds the "real" DLL, the attacker's code will be executed.

Consider the following scenario: Suppose that you use a web browser to download files, and you have some directory where you put your downloaded files. As time goes on, that directory gets filled with items that you've downloaded. Occasionally, you may open one of the trusted programs that you've explicitly downloaded and run it from your browser's download manager or from Windows Explorer.

If this scenario seems plausible, you may have inadvertently executed malicious code! This risk is even greater if you use a web browser that saves files to your computer without prompting, such as Google Chrome or an older version of Apple Safari for Windows. It's important to note, though, that any web browser or other application is at risk here, too, because the DLL search order behavior is a feature of Microsoft Windows.

What can you do to protect yourself from this kind of attack? For starters, make sure that your web browser is configured to prompt you before downloading a file. For example, Google Chrome has a preference called "Ask where to save each file before downloading." Configuring your web browser to prompt you before downloading a file can help prevent a directory from being "poisoned" without your knowledge. The most effective protection, however, is to move a file to a trusted (i.e., empty) directory before executing it. Before running a program in Microsoft Windows, it is not enough to verify that you trust the program itself. You must also trust the directory from which the application is launched. A cluttered download directory is not trustworthy.

Windows Vista does not appear to be vulnerable to directory poisoning. In my testing, Vista seems to give DLL search order priority to the system directory rather than to the executable's current directory.

Update (August 26, 2010)

The difference in behavior between Windows XP and Vista was caused by the KnownDLLs registry key. The sample application I used to test directory poisoning used the setupapi.dll file for hijacking. On Windows Vista, setupapi.dll is listed in the KnownDLLs registry key, which means that on the Vista platform, setupapi.dll will be loaded from the system32 directory. On Windows XP, setupapi.dll is not listed in KnownDLLs, which means that it will be loaded from the directory where the application resides. My initial conclusion was incorrect. Windows Vista and 7 are vulnerable to directory poisoning.