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.
