DLL Hijacking: Facts and Fiction

By Oliver Lavery

It’s been interesting watching DLL hijacking grow from interesting phenomena  to a full-on snowball of hype and FUD over the last few days. As of this writing Google turns up 152 news articles on the subject. The vast majority of coverage is calling this a “new class of attack” and pointing out how “over 30 zero-day vulnerabilities have been found so far!”. The only way to paraphrase many of the headlines is: “Panic!”

Fear and panic, while good for security companies and media outlets in the short term, are not responses that benefit users. Risk management isn’t based on emotion, it’s based on a well-reasoned assessment of risk. In the long run panic can draw attention away from the day-to-day issues which may represent more risk to the enterprise.

DLL hijacking simply isn’t the same as a typical zero-day vulnerability. The technical details of the attack have been covered in depth elsewhere, so I won’t go into them here, but technical details without context can lead to exaggerated conclusions. Let’s take a step back and look at this in the context of history and fact…

First and foremost, DLL hijacking is not a new zero-day vulnerability. It’s been issued a Bugtraq ID since 2000. I suspect most people who have worked with C or C++ on Windows were already aware of the surrounding issues, including the Windows DLL search path. It certainly used to bite me when I was a full-time coder and accidentally put an old-buggy version of a DLL I was working on in the wrong place! On Unix DLL hijacking (shared library preloading) is a feature accomplished through the LD_PRELOAD environment variable.

The root of this problem lies in the past in an industry far removed from internet security. Many years ago a Microsoft design error included the current working directory in the list of directories Windows will search when looking for a DLL. As a result, it was trivial to use a directory under your control to trick an application into loading the wrong copy of a DLL, which could be a security flaw in some circumstances. Later as the Internet grew and computer security became a pressing issue, Microsoft mitigated this problem by introducing the SafeDLllSearchMode registry key. It wasn’t a perfect solution, but it did help the situation. Finally this behavior was enabled by default in Windows XP SP2.

Prior to SafeDllSearchMode virtually every windows application was vulnerable to this sort of DLL Hijacking attack. Did it cause infopocalypse? Did SCADA systems burst into flames world-wide? Nope.

Yet, ten years later, the fact that this DLL hijacking technique can still be used in some very specific circumstances is apparently cause for panic. The number of applications that this impacts is apparently big news. Lists are being published. Headlines read that “exploit code hits the wild”.

The reality is anyone who can stumble through the DLL project wizard in Visual Studio can write an ‘exploit’ for this vulnerability, and when the dust settles the lists will look a bit silly -- virtually every Windows application will be found to be vulnerable in one way or another.

Does it matter? Yes. Is it cause for concern? Probably. Should we all panic about this new ‘glut of zero-days’? Not at all.

The key thing to understand is there are tons of mitigating factors for this sort of attack, and that’s why it isn’t widely exploited even though it’s been known for a long time:

• The user must open a document from a WebDAV share or a network file share. Reports that say that “opening a file from the Internet” can cause a victim to be compromised are extremely misleading. That document could be opened via a link in an email, however, which is cause for concern, as this sort of attack will always succeed for a small population of users.

• The attacker must guess what vulnerable software you have installed. Since we’ve seen reports that MS Office and other ubiquitous applications are vulnerable, that isn’t very hard right now. It’s safe to assume we’ll see patches in the coming weeks, at which point attackers will have a much worse success rate as they have to predict which software, and in some cases what version of a program, a victim has installed.

• There are easier ways to trick a user. Similar email attacks have been fairly successful this year, but they used much simpler vectors. PDF files and Word documents are things users are used to receiving in email and opening without a second thought; so zero-day vulnerabilities in Acrobat or Word are a big deal. Call me an optimist, but I’d like to think users might pause to think harder when a weird looking link in email opens up an Explorer window on a WebDAV share on the Internet. That’s just not a normal use-case.

• Virus software can help. Some people are reporting that anti-virus can’t block this sort of attack. That’s largely false. It is easy to write a malicious DLL, but it’s just as easy to create an A/V signature for a malicious DLL as any other malware.

To make a prediction, we’ll probably see email borne attempts to exploit DLL hijacking  circulate for a while. They won’t be that effective, and we’ll all go back to business as usual when the next big zero-day in a common file format surfaces.

That said, within the enterprise, where opening files or even applications from shares is commonplace, this could represent a real risk from an inside attacker. Please do head over to Microsoft and deploy the fix, there’s really no good reason to load a DLL from a WebDAV or other share in a security conscious environment.

Oliver Lavery is the director of security research and development at nCircle.

Commenting on this Article is closed.