Microsoft has released a point-and-click tool to help protect Windows users from a broad category of security threats that stem from a mix of insecure default behaviors in Windows and poorly written third-party applications.
My explanation of the reason that this is a big deal may seem a bit geeky and esoteric, but it’s a good idea for people to have a basic understanding of the threat because a number of examples of how to exploit the situation have already been posted online. Readers who’d prefer to skip the diagnosis and go straight to the treatment can click here.
DLL Hijacking
Windows relies heavily on powerful chunks of computer code called “dynamic link libraries” or DLLs. Each of these DLLs performs a specific set of commonly-used functions, and they are designed so that Windows can share these functions with other third-party programs that may want to invoke them for their own purposes. Many third-party apps will load these DLLs or bring their own when they first start up and often while they’re already running.
Typically, DLLs are stored in key places, such as the Windows System (or System32) directory, or in the directory from which the application was loaded. Ideally, applications will let Windows know where to find the DLLs they need, but many do not.
The potential for trouble starts when an application requests a specific DLL that doesn’t exist on the system. At that point, Windows sets off searching for it — looking in the above-mentioned key places first. But eventually, if Windows doesn’t find the DLL there or in a couple of other places, it will look in the user’s current directory, which could be the Windows Desktop, a removable device such as a USB key, or a folder shared on a local or remote network.
And while an attacker may not have permission to write files to the Windows system or program directories, he may be able to supply his own malicious DLL from a local or remote file directory, according to the U.S. Computer Emergency Readiness Team.
Several months ago, experts from a Slovenian security firm warned that hundreds of third-party applications were vulnerable to remote attacks that could trick those apps into loading and running malicious DLLs. According to the Exploit Database — which has been tracking confirmed reports of applications that are vulnerable to this attack — vulnerable apps include Windows Live Mail, Windows Movie Maker, Microsoft Office Powerpoint 2007, Skype, Opera, Medialplayer Classic and uTorrent, to name just a few.
Roughly one week ago, Microsoft released a workaround tool to help users and system administrators blunt the threat from all of this by blocking insecure DLLs from loading from remote and local file sharing locations. But the tool wasn’t exactly made for home users: After you installed and rebooted, you still had to manually set a key in the Windows registry, an operation that can cause serious problems for Windows if done imprecisely.
On Tuesday, Microsoft simplified things a tiny bit, by releasing one of its “FixIt” tools to make that registry fix so users don’t have to monkey around in there. Trouble is, you still need to have installed the initial workaround tool before you can install this point-and-click FixIt tool.
It’s tough to gauge whether DLL hijacking poses the same threat to home users that it does to users on larger enterprise networks. Microsoft maintains that this class of vulnerability does not enable a “driveby” or “browse-and-get-owned” zero-click attack, but the attack scenarios Redmond describes where a Windows user could get owned by this attack probably would work against a majority of average Windows users.
And while it may take some time for developers of vulnerable third-party apps to fix their code, Microsoft’s interim fix does add a measure of protection. If you’d like to take advantage of that protection, visit this link, scroll down to the Update Information tab, and click the package that matches your version of Windows. Install the fix and reboot Windows. Then visit this link, and click the FixIt icon in the center of the page and follow the installation prompts.
Further reading:
An excellent writeup on this from SANS Internet Storm Center incident handler Bojan Zdrnja.
A discussion thread about this on DSL Reports’ security forum.
Thanks, Brian!
When I read that Microsoft Windows would look for dll’s *IN THE CURRENT DIRECTORY*, I was aghast. We’ve known in the Unix world that this is a giant security hole since, like, at least the early 1980’s, which is why no currently-shipping Unix or Unix-alike (Linux, FreeBSD, etc.) ships with “.” (current directory) in its $PATH or $LDPATH. You’re just asking to get Trojan’ed if you are stupid enough to ship an OS with current directory in any kind of path, whether DLL or binary execution. I realize that Microsoft completely ignores all the security knowledge that us old-timers developed on Multic and Unix because it’s “not invented here”, but sheesh. This is just utter ignorance on their part and should have never survived past the first release of Windows NT.
My understanding was that Linux, at least, looks in the current working directory for shared objects and dot files. That’s certainly how I’ve coded apps that run on Linux. Look in the CWD for the config file. That’s why Linux doesn’t have that horror known as the Registry.
My understanding is that Windoes DOES NOT do this (relatively reference DLLs) but many applications commit this felony. Which is why the App Developers need to fix their code, and why Redmond can’t just issue a *fix* that secures the applications that run on it. Therefore any *nix system could potentially fall victim to exploitable applications that relatively reference any outside code, it doesn’t need to be a .DLL. When you just Bash Windows the way you did you continue the stero-type the rest of us old-timers who are opened minded (and open sourced) would rather avoid. To the rest of the people and developers reading this: Microsoft makes headlines, open source does not. Learn how to code correctly from the start, it should never be an after-thought.
And why should applications be allowed to do this? In *NIX environments, most all (if not all) applications live in *user* space and are subject to user security settings.
In Windows, the permissions are a bit more global (read “System”, “kernel”, etc.)… Why should *I*, a user be subject to (at risk to) bad decisions made by some ***application***???
Sheesh… It’s just bad security design.
@wiredog
$HOME not CWD. And config files only, not generally executables – the notable exception being .profile.
Portable apps are probably immune to this problem. By their nature, portable Windows apps are self-contained in a single folder and thus not likely to be loading DLLs from anywhere other than the folder in which they reside.
@wiredog
Linux (and Unix) do not search the current directory for executables. See example below.
rgibbs@rich90:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
rgibbs@rich90:~$ which date
/bin/date
rgibbs@rich90:~$ cp /bin/date ./etad
rgibbs@rich90:~$ ls -la etad
-rwxr-x— 1 rgibbs rgibbs 55820 2010-09-01 16:00 etad
rgibbs@rich90:~$ etad
bash: etad: command not found
rgibbs@rich90:~$ ./etad
Wed Sep 1 16:00:41 EDT 2010
rgibbs@rich90:~$ date
Wed Sep 1 16:00:43 EDT 2010
rgibbs@rich90:~$
The current directory, or your home directory, is not in the PATH unless you put it there — a Real Bad Idea.
Rich
What does $PATH have to do with the way I write an app?
What is stopping me from writing some stuipid program in C that calls a file subrouting in my current directory?
Sure the user may not be able to fire off my program because it isn’t in the $PATH env variable, but if a program has CODE that calls a file in a relative way, that Program is exploitable in that I replace whatever file is called in my program with code that does “find . -name whatever.xxx | xargs rm” or Format C:\
get it? As long as the user is dumb enough to have this sort of App on their computer and they run it (yes they would need the proper authorization) they could fall victim to this attack.
The key is that certain volumes are writable, can retain execute permissions, and enable users to be tricked into saving executable content which is then found when the user is convinced to load another saved file.
From the perspective of a traditional programmer, the fault is on the user’s side, or perhaps lies at the feet of whatever “AV” software is running around which should block junk from getting into the temporary folder.
Unfortunately, users aren’t smart. Nor were AV programs doing their job.
As such people went around pointing fingers at everyone.
This isn’t really much different from the case of an evil person providing a file which functions as an .hta (html application) and somehow convincing a user to download it with an ignorant browser (anything that isn’t IE) and then open it with IE. HTML Files loaded locally aren’t entirely harmless, they’re at best _mostly_ harmless.
Please note Fixit’s system-wide setting of 2 won’t give max protection but Microsoft’s other recommendation of 0xffffffff will.
Thanks for the info on how to install the MS fix. Since this is a two step process I am afraid most users will think it is too “hard” to do. It took a total of about three minutes from start to finish for both steps.
what a pathetic vuln
what a pathetic ‘tool’
fix the problem and be done with it.
score 0 for microsift, again.
wiredog, I don’t want you working for me! I don’t want config and library files replicated in each folder on the system. I want only one copy. I think this “.” defect was there strictly for rapid prototyping with the idea somebody would not be so stupid as to leave it that way in the final shipped code. The most secure solution is the same for both Windows and Linux and for binaries, dynamic link libraries, and config files on what should be attempted to be used and when. The order should be: 1. system. 2. local – usr/local on ‘nix and “%ProgramFiles%\Common Files” on Windows. 3. app folder 4. user, and 5. “.”. But should only be for the exe path, not for dynamic link libraries and config files. If possible “.” should not be there at all. Unfortunately, “.” was implicitly first on Windows at one time because it isn’t in the path. Now what is preventing Microsoft from putting “.” last for exes? I apologize if they have corrected this design defect but years ago my tests revealed “.” implicitly came first. It needs to be changed so that “.” comes last if it isn’t already that way. I guarantee it is implicit because it still isn’t in the path. I have too much to do to run another test. If this fix for the DLL breaks some sloppy programmers code, so be it. But “.” should NEVER have been in the DLL path at all. This “fix” is leaving millions of home users vulnerable. Like taking out the autorun, this fix is way above Aunt Martha’s (a ficitious normal person) ability to implement it. I think Microsoft should give the programmers an ultimatum and tell them they have two months to no longer depend on “.” for their DLLs and and config files. The programmers have that time to fix their code and shove the patches out. At the end of the two months, Microsoft needs to ram these changes onto all Windows operating systems with a monthly security update with a method to turn if back off for corporate users. Given that Conficker and probably new forms of malware depend on autorun they should also patch that as well. Just turn autorun off. I can tell you for a a fact that Aunt Martha can’t turn autorun off herself either:
http://securemecca.com/public/NoAutoRun.7z
Autorun is a security hell, especiially with the newer Flash memory sticks. Actually a home user is less likely to be affected by this DLL path “Fix” once Microsoft fixes their own apps than a corporate user would be. Don’t chortle Linux people. Usually there is no LDPATH. I wished there always was one and again, I don’t want “.” in it. This isn’t optional – it is mandatory. For those confused readers out there I use Linux (currently OpenSuse 11.2 and Ubuntu 10.04), OpenBSD (when security really matters), and Windows XP Home and XP Pro. So I am not an OS basher. I am a true security person and represent the end user who could care less what they are using. They just want something to get their work done and their bank account to not have its funds siphoned out of it. If that philosophy isn’t congruent with yours, c’est la vie. I even have somebody I work with that helps create the security products you people use have his machine get infected. He runs only Windows How do I know he is infected? He is being redirected to mp.apmebf.com when going to a PayPal or eBay account creation. Fortunately my blocking hosts file blocks it. But he still has an infected machine. I am going to add a rule to the PAC filter to block the apmbef.com domain. Bu he is not a normal user. He is a geek, and he still got infected despite all the care that he has taken. I have also had two sisters that had their computers infected and a high profile bicycle racer whose better half’s Windows machine that was infected obligingly shoved all the top luminaires in the sport of bicycle racing into my email box. We will ignore for the moment that I could have found all of those email addresses on my own. When I wrote to the bicyle racer to inform him of his infection he replied saying he used a Mac. I hope his better half also has a Mac now. This is no longer hypothetical – millions of people are being adversely affected by the stupid decisions of just a few people. Do I need to draw a picture for you?