Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


The Windows DLL Loading Security Hole

So what can you do? Follow Microsoft's guidance on DLL security. In particular, it's a bad idea to rely on the system PATH environment variable for your application to find its DLLs. The PATH lies behind the current directory in DLL loading priority:

  1. The directory from which the application loaded.
  2. The system directory.
  3. The 16-bit system directory.
  4. The Windows directory.
  5. The current directory.
  6. The directories that are listed in the PATH environment variable.

Microsoft docs refer to this order as "Safe Search Order" or "SafeDllSearchMode" and it is enabled with a registry key. This setting has been default-on since Windows XP SP2 and supported since Windows XP SP1. If you are working with clients older than that, then DLL search order may be the least of your problems, as even XP SP2 is no longer supported.

Of course, if you specify a fully-qualified path in your call to LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute, no search is necessary. So that's always the best way, if you can. You can also make sure your app runs the correct DLL by using DLL Redirection or a Manifest. You can specify a particular search order for the app with the SetDllDirectory function.

Microsoft's Dynamic-Link Library Security page also has instructions for how to use the Process Monitor tool to observe exactly what DLLs your apps are loading and from where.

You may have already noticed a steady stream of application security updates related to this issue, including some from Mozilla. A recent security update of Safari from Apple fixes a nasty variation on the same bug, that of the EXE load search order. When you load executables you have to be aware of the same problem. Mitja Kolsek of ACROS says that "the search path for executables is actually much worse, even worse than it used to be for DLLs before Microsoft introduced the 'safe search order.'" Unless you specify the full location of executable, Windows will first look in the current directory.

Once you understand the problem it seems rather obvious, and remarkable that it hasn't been noticed before. This also represents a gap in the guidelines of the Microsoft Security Development Lifecycle (SDL), the secure development practices created by Microsoft for its own use and available to anyone through the Creative Commons License. I asked Microsoft who admitted as much:

Given the newly-found Internet attack vector, we are currently updating the SDL to include guidance and tooling for developers and testers so they can prevent or find, triage and fix potential DLL preloading vulnerabilities in their products. Once we have finished the SDL guidance, we will make a version of the guidance and tooling documentation publicly available as soon as possible."

You might think that the answer would be to remove the current directory from the search order, and we asked Microsoft about just that. It seems this possibility is not in the cards, as it would break a substantial number of customer installations, and this is the clearest evidence you could ask for that this is a serious problem. It proves that the number of apps which rely on the current directory for DLL loading is large.

For the long term, Microsoft has released an update which enables a new registry key called CWDIllegalInDllSearch that lets users and administrators control the loading of DLLs in their own systems. You can't rely on this being loaded and Microsoft won't be turning it on by default. With no systemic solution coming from Microsoft it's up to you, the developer and publisher of the application, to make sure it's done right and get any fixes to your users.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.