DLL Hijacking Redux

Someone once suggested there is nothing new under the sun, and that's certainly true with this week's spate of reports about DLL hijacking attacks in Windows.

This is a well known vulnerability dating back many years. New reports that that specific Microsoft applications fall prey to this vulnerability are not at all surprising (http://tinyurl.com/33btjkh).

Microsoft is quoted by Computerworld (http://tinyurl.com/23ag8kb), saying:

"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."

Assessing this statement requires a brief review of the facts. First, this is a vulnerability driven by the fact that Windows will search in all kinds of places to find a DLL that your application requests to be loaded, if you application is so "unsecure" as to identify that DLL only by file name instead of a fully specified pathname.

Why would applications fail to use a fully specified pathname? One good reason is compatibility: Microsoft DLL's are not consistently in the same location across different versions of Windows! Therefore software striving for compatibility needs to allow Windows to search for the DLL, or search itself. A second reason is simply because Windows allows it and thereby "it's easier".

Windows first looks for the DLL by name in the current process's current ("working") directory. That's where an attacker can easily load their own replacement DLL under the same DLL name (through a wide variety of means, none legitimate but all relatively easy to perpetrate), if (as is usually the case) the current directory is not where the named DLL resides. The next time the application runs, viola, they have their own software now running on the computer. What can it do? Literally, just about anything, including quickly load other more subtle and pernicious bot-ware, key loggers, system scanners, etcetera.

Can applications operate in a manner to avoid the vulnerability? Yes, they can, but doing so is more complicated for the application developer. The key is to always load a specific DLL in a specific directory using a fully specified pathname. This in turn can create its own application compatibility issues, as any given path name to a system DLL is not guaranteed to be the same from Windows version to version! This is the true heart of the design issue, because any attempt to deal with this multiplicity of DLL locations across Windows versions in a single version of an application requires the application perform a "search" for the DLL across different directories...which is exactly what Windows does automatically for you and which opens up the application to a replacement DLL attack!

We here at Arxan are looking at this problem in an orthogonal manner, by identifying opportunities to validate that the proper DLL was loaded, regardless of its originating location. Those are the kinds of application internal security features we are quite good at. Note the elegance of this kind of solution: it doesn't require any application source code changes (because our technology inserts such checks directly into the binary application code), it creates no new dependencies on Windows specifics such as specific DLL locations in this or that version of Windows, and it is a security solution that migrates with the application itself.

To end with another ancient aphorism, if you want a job done, best to do it yourself. If you want your applications secure, don’t trust in the operating system to provide that security: secure your applications yourself!