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