This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 79%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I'm trying to figure out how to securely link a dynamic-link library(.dll) at load-time. I want to make sure that the .dll I'm linking to is in fact the one I expect, and not a malicious one.
I have read the Dynamic-link library security article, but most of it is referring to linking securely at runtime, where you make calls to LoadLibrary , rather than load-time. So I am not using any path to the .dll or any API function to load the .dll--I am linking to the import library when I build my application, and that tells the application to link to the .dll at load-time when the app is starting.
It looks like for load-time linking, the two things you can do are DLL redirection and specify manifests. Now, DLL redirection seems to only change the search order of the directories for the .dlls; this doesn't help with the case where an attacker replaces a .dll in a given directory with a malicious .dll. I want to protect against that case by checking the signature of the .dll(again, at load-time, meaning I can't just put the signature-checking in my application code).
As far as manifests, I tried creating a manifest where I specified a dependency with a publicKeyToken as mentioned in this StackOverflow question. However, after testing, this had no effect. I was able to link an unsigned .dll even though I had specified the publicKeyToken for that .dll in the manifest dependency.
So how can I ensure that I only link a signed .dll at load-time?
@Aaron You can apply the mitigation requiring signed Microsoft binaries to a process that runs as a Windows Service through the Image File Execution Options registry key. Consequently, you don't need an intermediary between the service control manager and your service executable. The same holds true for an executable that is not a service. The policy is applied directly and no launcher process is needed.
For example -
Wow, I'm not sure how you found this--it doesn't appear to be documented by Microsoft. I only see this individual's documentation of it: https://theryuu.github.io/ifeo-mitigationoptions.txt. But thank you! I will say, the bottom of that documentation does have a disclaimer that using any of these options may cause undefined behavior/break something; I assume it says that since the options aren't really documented by Microsoft.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(0, 2%, 10%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAM%3C/text%3E%3C/svg%3E)
Hi Aaron,
Did you manage to get this method working? if so can we discuss in details how you did it?
Refer to the answer and discussion at https://learn.microsoft.com/en-us/answers/questions/1189539/loadlibraryexw-returns-error-invalid-image-hash-on with respect to limiting dynamic link library loading to signed binaries. Also, take a look at How can I try to escape the disease-ridden hot-tubs known as the TEMP and Downloads directories? and the documentation for the /DEPENDENTLOADFLAG (Set default dependent load flags) linker option. You should be able to obtain a reasonable level of security by installing your application and its non-system dll dependencies in a secure file system location (i.e., C:\Program Files, etc.) and limiting dll loading to the application directory and System32 using the linker option above.
Thank you for your answer. The second recommendation, using the /DEPENDENTLOADFLAG to control the directories that are searched when load-time linking the DLLs is helpful.
However, the first link--for limiting dynamic library linking to signed binaries--looks like it only applies to runtime linking and not load-time linking. Because the answer mentions calling SetProcessMitigationPolicy before calling LoadLibrary; this has to do with application code which is only going to be run after load-time DLLs are already linked. Is there anyways to limit load-time dynamic linking to signed DLLs?
I also mentioned in my comments in the linked post that you could use a launcher process to ensure that the process mitigations are in place when the child process is started. If this is done then the enforcement of signed binaries is applied at load time for the child process.
I see, that makes sense. Well I'm doing this in the context of a service--the service .exe should only be linking to signed .dlls. I'm not sure if there's something other than a launcher process, that could be used to specify the process attributes of a service before it's run. Because the service manager is the "launcher", in that it starts the service. So I'm not sure that it's possible to insert a launcher of my own in-between the service manager and my service. (While keeping my service as a service, which receives control codes, events, etc. from the service manager)
I suppose you could use your service process as an intermediary. It could start a process with the mitigations that we've discussed and use some form of IPC to communicate events and control codes to the child process.
