Microsoft just released Security Advisory 2269637, warning of an entire class of new zero-day attacks that take advantage of the way many popular Windows programs are written. Perpetrators -- likely to appear in the next few days -- won't take on Windows directly. Rather, they'll rely on how Windows finds and assembles pieces of programs to get their nefarious code to run.
Known variously as "DLL hijacking," "DLL preloading," or "binary planting" attacks, I tend to think of the approach as a "path exploit." Back in the early days of Windows -- and DOS before it -- the sequence of DLL search locations was defined by something called a Path variable. That's why I call it a path exploit.
[ Get your systems up to snuff with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]
There's a lot of hand-waving and high-falutin' programming terminology floating around, but at its core the attack goes like this: You have a program called, oh, Senuti.exe and you run it all the time -- it's a big-name program from a major manufacturer. Whenever you double-click on a file with a name that ends in .sen, say, the Senuti.exe program kicks in and loads the .sen file. Easy.
The guys in black hats have been watching Senuti.exe and they know that every time Senuti.exe runs, it fires up a program called, let's say, Whizbang.dll. The guys in black hats also know that the Senuti.exe program doesn't specify exactly where Windows should find Whizbang.dll. Instead, they've discovered that the Senuti program just calls "Whizbang.dll" and lets Windows find it. That's a common (but not recommended) programming practice.
If the program doesn't tell Windows where to find Whizbang.dll, Windows goes looking for the DLL in a very rigidly defined series of folders (details on the MSDN DLL Search Order page). By default, Windows starts by looking in the folder that contains the Senuti.exe program, then goes to the system folder, then the Windows folder, then the current directory, and so on.
The plot thickens. The guys in black hats have been looking at a lot of programs. They find out that Senuti.exe calls Whizbang.dll and that Whizbang.dll isn't normally located in the high-priority folders. It isn't usually in the folder with the Senuti.exe program. It isn't in the system or the Windows folder. So the guys in black hats put a .sen file and their own, jiggered Whizbang.dll file in the same folder.
Here's what happens. You double-click on the folder -- say, on a shared drive or on a USB drive -- that contains the .sen file and Whizbang.dll. Windows Explorer normally shows you .sen files, but it doesn't show you DLLs, so the contents of the folder look just fine. You see the .sen file, and you double-click on it. Bingo. Windows runs the subverted Whizbang.dll file that's inside the folder.
Windows doesn't try to authenticate Whizbang.dll. It just looks for a program called Whizbang.dll by scanning through a specific list of locations. The first Whizbang.dll it encounters wins, and it runs. You've been pwned.
Companies that publish big-name programs like Senuti.exe should have their programmers figure out exactly where to find subsidiary programs like Whizbang.dll. The program should never say, "Hey, Windows, go out and run the first Whizbang you find." Microsoft programming guru David LeBlanc blogged about that years ago. But programmers get lazy, and systems get complicated. In the end, many hundreds of popular programs, including the ones you use every day, take the short way out -- and now, we're being told, they leave you exposed.
There's nothing particularly new or revolutionary about path exploits; they've been around a long, long time. It's just that, this past week, several high-profile websites have started talking about the problem and showing how the DLL search path can be used in novel ways to run a program surreptitiously. H.D. Moore of Metasploit fame has posted his rationale for releasing information about the exploit, and is actively disseminating exploit kits to help find applications that call DLLs without specifying their locations.
I haven't heard of any new-generation path exploits, but I believe it's only a matter of days before they hit the fan. Microsoft has a couple of mitigations that involve Registry changes detailed in the Security Research & Defense blog. They seem to be effective for the specific infection methods that involve network shares. But the core problem remains -- and won't be solved until application vendors get their code cleaned up.
This story, "Heads up: A whole new class of zero-day Windows vulnerabilities looms," was originally published at InfoWorld.com. Get the first word on important tech news with the InfoWorld Tech Watch blog.