Earlier this week I wrote in Tech Watch about a whole new class of Windows zero-day vulnerabilities, warning that a wave of attacks would arrive soon.
Like night after day, the exploits have appeared, as Gregg Keizer explains in his Computerworld article "Windows DLL exploits boom." Two separate websites -- the Exploit Database's DLL Hijacking Vulnerable Applications list and Peter Van Eeckhoutte's DLL Hijacking Unofficial list -- currently have details on more than 80 Windows applications that are susceptible to this kind of security breach.
With so many application heavyweights in the bad guys' crosshairs -- such programs as AutoCAD 2007, Illustrator CS 4, Dreamweaver CS 5, Google Earth and Chrome, uTorrent, PowerPoint 2007 and 2010, Word 2007, Groove 2007, Visio 2003 and 2010, Foxit Reader, Firefox, Thunderbird, and WinRAR appear on the vulnerable lists -- you can safely assume we've only seen a tiny slice of all the exploits due to plague us shortly.
The vulnerabilities won't go away for good until the software manufacturers (including, notably, Microsoft itself) patch their applications. In the interim, we're left with rock-and-a-hard-place choices.
Microsoft's Knowledge Base article 2264107 includes programs that enable a new Registry entry for Windows. Once you run the applicable program, you can set a Registry key called CWDIllegalInDllSearch to force Windows to ignore the Current Working Directory when searching for an inadequately specified DLL program. (See my original article for details about why that's important.)
Unfortunately, as described in the Comments section of the SANS Internet Storm Center entry for DLL Hijacking, the CWDIllegalInDllSearch key is an all-or-nothing option. If you tell Windows to ignore the Current Working Directory for programs invoked to handle networked files (specifically WebDAV and SMB), you also prevent Windows from searching the CWD for programs invoked to handle plain old local files. And that, according to the SANS comments, breaks Outlook and Chrome, among other programs.
Let's take a deep breath, step back, and take a closer look.
DLL Hijacking requires two files: a data file (more accurately, a file with a filename extension that's associated with a program that's susceptible to DLL hijacking) and a jiggered DLL file. In most cases, both files have to reside in the same folder. Yes, the rogue DLL can be in a different folder, but if somebody can plant a bad DLL in your system folder, you're hosed anyway.
Most companies block network access (WebDAV and SMB) at the corporate firewall. So most companies (and most users) are primarily concerned about getting infected by a pair of files sitting in a folder on a USB drive, a network share, a CD, possibly inside the same ZIP file, or some similar location. Typically, the victim navigates to the folder in Windows Explorer and double-clicks on the data file, thus invoking the vulnerable program that runs the jiggered DLL, which sits in the same folder. That isn't the only way to get infected from a DLL hijacking exploit, but from what I've seen it's by far the most common.
I have two recommendations.
First, never double-click on a file that's in a potentially compromised location. Drag it to your desktop, then open it.
If you want to open a Word document that's sitting on a USB drive, for example, drag the file onto your desktop and open it from there. If you see a PPT file on a network share, drag it to your desktop and open it. Have a Visio VSD inside a ZIP file? Extract the VSD from the ZIP first, then open it. Since the DLL hijacking trick (almost) always requires that the two files sit in the same folder, simply dragging the data file somewhere else breaks the link and foils the hijack.
Second, make Windows show you filename extensions and hidden files.
I've been preaching about this for a decade, but every Windows user should be allowed to see filename extensions and hidden files. If you or your users are savvy enough to spot a DLL file sitting in an unusual location, you could readily prevent a hijacking.