Is there any way to disable loading of satellite DLLs for MFC programs?

Hermann Walth 20 Reputation points

According to this help page, any application or DLL created with MFC will attempt to load localized resources from satellite DLLs such as exampleENU.dll or exampleLOC.dll.

We have built a legacy application using MFC, but we do not use this particular mechanism to provide localization. However, we want to preempt any potential security risks that stem from our application trying to load DLLs that we do not actually use or provide.

Is there any way to disable this behavior of an MFC application? We do not want our application to attempt to load any of these DLLs, as we see a potential vulnerability to arbitrary code execution should an attacker deposit a malicious DLL under such a name within the DLL search path.

It should perhaps be noted that most of our application's functionality is spread across multiple C++ DLLs, each of which links against MFC, whereas the main application .exe does not link against MFC itself. The observed behavior is that each of our module DLLs attempts to load its own set of localized satellite DLLs, which is what we want to avoid.

A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
3,553 questions
{count} votes

Accepted answer
  1. Michael Taylor 49,071 Reputation points

    Been a long time since I've done anything with MFC but I don't know how much of a security risk it actually is. It is a resource DLL so the only thing that is used out of it is the resources that are embedded. By default they wouldn't be a security risk. I suppose if the DLL has malicious code in the startup block when the DLL is loaded then it could do something but that is about it.

    However from a security point of view, if a malicious user can drop a binary into your application's directory then your system is already compromised. It is too late at that point anyway so protecting for this one class of risk doesn't really protect the rest of your system. For example suppose you don't allow loading of resource DLLs, fine. As a malicious user I simply drop a DLL with the same name as: a system DLL (which Windows will load first by default), one of your own DLLs, or even your EXE. In all cases I have just injected myself into your process and there is nothing you can do to stop it short of ensuring all your binaries are cryptographically signed and your app enforces it.

    But if you really want a "feel good" option then MFC loads DLLs by following a well defined search order for the resource DLL to use. Since that is based upon the locale of the machine you would either need to provide a resource DLL for all languages you need to support or at least English. This would prevent a malicious user from dropping their own (further down the chain). But, again, if they can drop binaries into your app directory your system is already compromised.

0 additional answers

Sort by: Most helpful