Microsoft's DLL exploit mess could eventually lead to safer libraries. Until then, get ready for a manual fix.
Even though Microsoft is so far refusing to patch the critical Windows DLL vulnerability that has become the source of an ever growing number of new exploits, you can protect your systems now. But it won’t be easy.
The fix involves manually auditing which applications are vulnerable and then applying Microsoft’s new fix-it tool. Many makers of Windows software, such as Wireshark, are also promising patches for their apps.
By now, many of you have read articles explaining the problem. If not, here’s a few of my favorites:
Windows DLL exploits boom; hackers post attacks for 40-plus apps: explains the problem of how attackers can get applications to load a malicious library, if the attacker had been able to plant one in the same directory as the application.
Microsoft DLL Hijacking Exploit in Action: A video that shows the exploit in action using Metasploit. (1:38)
U.S. Cert’s Alert : Microsoft Windows Insecurely Loads Dynamic Libraries: Good description of the problem along with workarounds for both admins and developers. A long list of links to what individual application makers have said and done to fix the problem, from Apple through VMware.
Microsoft’s two descriptions of the problem: One as a blog post from its Security Response Center. More details in a document disguised as a best practices guide for developers. (But this document says it was published August 19 even though other documentation can trace this flaw in Windows back for about a decade. It’s a little late for such best practices advice, methinks).
“Unofficial” list of dozens of affected applications.
Rapid7’s HD Moore’s blog post explaining the (rather ugly) history of this exploit’s discovery.
I would love to slide off into a rant about the HD Moore post — and how security researchers have gotten just as bad as application vendors when it comes to responsible disclosure, finger pointing and the like. But the most important thing to know at this point is that Microsoft has published a tool that will control the search path an application uses to find and load the DLL. This should safeguard your applications from this attack.
Microsoft’s tool is a new registry entry called CWDIllegalInDllSearch, and you’ll have to manually install it (Again, you can find that tool for all versions of supported Windows here.)
According to Microsoft, the tool does the following:
The update allows the administrator to define the following on a system-wide or a per-application basis:
- Remove the current working directory from the library search path.
- Prevent an application from loading a library from a WebDAV location.
- Prevent an application from loading a library from both a WebDAV, as well as a remote UNC location.
However, before you load the above tool, Microsoft recommends that you scan your infrastructure to determine which of your applications are vulnerable and it offers a tool for that too: The Process Monitor tool can be downloaded here from Technet.
Wouldn’t it be possible for Microsoft to somehow push this new registry entry out as a patch? Microsoft says it won’t patch because the problem isn’t a specific hole in a specific set of Microsoft applications. The truth is that it knows if it messes with an application’s ability to find its DLL, it has essentially broken the application. So for now, it will leave the fix to individual developers and to you.
After studying this issue over the past couple of days, I want to share the one silver lining I’ve found. In the long run, Metasploit and Microsoft’s testing tools may give application developers an easy way to ferret our weakness in the DLLs, some experts say, in much the same way that endless bugs with Microsoft’s ActiveX browser applications lead to using AxMan for ActiveX pen testing. And its about time, this class of bugs has been well-known for at least 10 years, according to the above linked blog post by HD Moore.
