Microsoft releases tool to block DLL load hijacking attacks

[monty slick]

http://www.computerworld.com/s/artic...ource=rss_news

By Gregg Keizer
August 23, 2010 08:42 PM ET

Computerworld - Microsoft on Monday responded to reports of potential zero-day attacks against a large number of Windows programs by publishing a tool it said would block known exploits.

However, the company declined to confirm whether any of its own applications are vulnerable, saying that it is currently investigating Microsoft-made software.

Monday's security advisory was its first public reaction to a wave of reports from researchers that developers have left a large number of Windows programs open to attack.

Many Windows applications don't call code libraries -- dubbed "dynamic-link library," or "DLL" -- using the full pathname, but instead use only the filename, giving hackers wiggle room. Criminals can exploit that by tricking the application into loading a malicious file with the same name as the required DLL. The result: Hackers can hijack the PC and plant malware on the machine.

HD Moore, chief security officer at Rapid7 and the creator of the Metasploit penetration testing toolkit, was the first to reveal the potential attacks when he announced last week that he'd found 40 vulnerable Windows applications. Moore was followed by other researchers who claimed different numbers of at-risk programs, ranging from over 200 to fewer than 30.

Microsoft went to lengths today to tell users that the flaw isn't in Windows.

"We're not talking about a vulnerability in a Microsoft product," said Christopher Budd, a senior communications manager with the company's MSRC, or Microsoft Security Response Center. "This is an attack vector that tricks an application into loading an untrusted library."

Because application developers, not Windows, are to blame, Microsoft can't patch the operating system without crippling an unknown number of programs that run on the platform. Instead, Microsoft and third-party developers must sniff out which of their programs are vulnerable, then patch each separately.

To ward off attacks until then, Microsoft has, as expected, released a tool that blocks the loading of DLLs from remote directories, such as those on USB drives, Web sites and an organization's network, all possible vectors.

"The tool restricts the loading of remote libraries on a per app [basis] or in a blanket implementation," said Budd. The tool can be downloaded using Windows version-specific links in a just-published support document.

more...

Find the appropriate package for your system at the bottom of the MS article, your Windows Updater will apply it. After the reboot use the "Fix It" link to configure the newly installed update.

[GreenEnvy]

For those unaware, I'll summarize the issue.

Years back, when Windows was in it's early days, they adopted the "current working directory" model. The way it works is when a program started up, it first looks in it's "current working directory" for it's DLL's.
If it doesn't find them there, it will continue down the order of directories (program files, windows, system32, etc..). In many cases, if you open a file just by double clicking it, the program will treat the folder the original file you clicked was in as the CWD.

This made sense at the time, but these days it's not good practice. There are hundreds of programs out there though that still look in their own CWD folder first, before checking the system folders.

This exploit is devious because someone can send you a download link to a file that is totally innocent, virus free. For example, they can send a link to a JPG image stored on a WEBDAV folder. That JPG is not infected with anything. If your preferred JPG opening program is afftected by this, it will look in the same folder the original JPG was for it's DLL's, it assumes that is the CWD. So, it will look in that same WEBDAV folder for it's DLL's when it starts. So, the virus maker has placed DLL files of commonly used JPG viewers in that folder, all infected. The JPG program will load the infected DLL and off it goes.

So it's not really a security bug in Windows per se, it's a former common way of doing things that has been exploited. Most apps are immune, but poorly coded software or older software can be exploited.

[monty slick]

I was surprised to see a LFD2 update yesterday to correct this problem. Lame Valve, lame.

[Fallout]

They are fixing this now? Back when I used to program on Windows this was never good practice. You figure they learn sooner. Must still be done for legacy support but I can't see a good reason anymore.

[monty slick]

Have I got this right in that it's not really Microsoft's fault the third party software devs don't specify paths to the needed dlls?

[Fallout]

If I can recall it's the lack of version control with DLLs that really is the crux of the problem. Windows doesn't care if a DLL is of a different version than the one stored in the system directory. I loads up what ever it finds first. I've encountered similar on other operating systems too but to a lesser extent. I guess it's just easier to work with shared code in CWD that's why it's so common. So it's more of the fault of developers.

[GreenEnvy]

That lack of version control is something lots of programs depend on though. Many program are written with a specific version of a DLL, and newer versions might break it. So the developer puts a copy in the programs "program files" directory and tells it to use that one. This is fine.
I think the fix is to disable loading of DLL's from outside the applications own program files location, windows files, or directories included in PATH. Have a warning popup when a program tries to load them from some other directory, and allow user to click continue after a scary warning message.

[Fallout]

That's actually a pretty decent solution.