Every now and then security advisories are published, warning about the risks of DLL injection.
Is there a general way to protect against DLL hijacking? I'm not familiar with the topic but requesting an absolute filename instead of a relative should be enough to protect against malicious DLLs in the working directory, shouldn't it?
If one can overwrite the DLL in my installation directory, one could also overwrite my executable thus a signature check seams useless.
DLL hijacking can be achieved for apps that request an DLL without using an absolute path. This triggers a search process and by placing the compromised DLL higher in the search patch that the real version, it is possible to have execute malicious code. However, your installation directory should be first in the search path, so it does not seem to be applicable in your case. Nevertheless you should be careful when passing sensitive data to your DLL, for example passwords and usernames.
In DLL Hijacking If, instead of a relative path, programmers start using absolute path, the vulnerability will be reduced. Reading the absolute path, the Windows or any other operating system will not depend on system variables for path and will go straight for the intended DLL, thereby dismissing the chances of loading the same name DLL in a higher priority path. This method too, is not fail-proof because if the system is compromised, and the cybercriminals know the exact path of DLL, they will replace the original DLL with the fake DLL. That would be overwriting the file so that the original DLL is changed into malicious code. But again, the cybercriminal will need to know the exact absolute path mentioned in the application that calls for the DLL. The process is tough for cybercriminals and hence can be counted upon.
Related
We are using an earlier version of a commercial application, doors.exe. The latest Windows 10 update broke it. Using msftedit.dll from Windows 7 restores it. Below are three scenarios I have tried. I don't understand why the first and last function the way they do rather than the way the documentation seems to say they should. Questions are in the first and last bullet.
If I create a directory doors.exe.local in the same location as the doors.exe executable and put the win7 dll into that directory, it is ignored and the one in SysWOW64 is used. Why isn't it using the .local directory?
If I put the win7 dll in the same directory as doors.exe, the win7 is used, whether or not I have an empty file named doors.exe.local.
If I put win7 dll into the doors.exe directory but don't create doors.exe.local redirect file, I expect that doors.exe would use whatever dll is loaded and only use the win7 dll if nothing was loaded. If I first start WordPad, which also uses msftedit.dll, and then start doors.exe, doors.exe still uses the local msftedit.dll. Why isn't it using the same dll as wordpad?
I am using Process Explorer to see exactly which dll is used by which process.
The above behavior seems contrary to what I have read in the MSDN documentation. https://learn.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection
What am I missing/not understanding?
Thanks,
Daniel
Do you know if the msftedit.dll is loaded with relative path? Or simpler, just by name? What you describe matches the standard LoadLibrary search order. First is the current working directory.
I am struggling with local redirection too. I have 3 PC where it works and 1 where doesn't.
I found how Dynamic-Link Library Redirection/Dot Local works. It uses some sort of caching per .exe instance to mark if redirection is used or not.
When you have an app.exe, first time when you run it on your PC it marks if it will use Redirection or not. Later this decision remains regardless if you put or remove the app.exe.local file/folder. I do not know yet where the cache value is stores. I searched the registry for the cache but haven't fount it.
Example 1: If you have app.exe and you do not have app.exe.local next to it and you run it first time, later never will use redirection. If you add app.exe.local redirection will not work.
Exsmple 2: If you have app.exe and you do have the app.exe.local next to it and you run it first time, later always will apply redirection. If you remove app.exe.local it still applies redirection.
I do not see the motivation for this confusing behavior.
Useful: if you want to reset the cache for an exe to use redirection or not, you can run in cmd:
touch app.exe
I'm trying to copy a file to System32 folder. I tried;
System.Environment.ExpandEnvironmentVariables("%windir%\system32")
Environment.GetFolderPath(Environment.SpecialFolder.System)
It didn't work. It always returns to C:/Windows . What should i do to get System32 folder ? Thanks.
Both of those work. You can verify you have the proper directory by setting a breakpoint on line 2 of your Button1_Click method and then inspecting the value of dir.
That being said, you really shouldn't be writing to the System32 folder (or really anything from the Windows folder down, with the exception of Temp). If you're trying to install an application on the end-user machine, you should be using an installer (and writing to the Program Files folder) instead.
Writing directly into the System32 folder isn't normally allowed (unless you've turned off access control and a lot of security features) as it introduces a huge security risk. You're also not guaranteed that it will even work on all systems because of different security controls that may (or may not) be in place.
I have an application that creates desktop shortcuts. To do this I have to reference the Windows Script Host Object Model. When I add it as a reference, it always creates the DLL, Interop.IWshRuntimeLibrary.dll, in the obj\x86\Debug directory, then references itself to it, rather than looking at wshom.ocx. Even if I add reference wshom.ocx it reverts to saving the file in the obj\x86\Debug directory. The problem is if I move my application to another computer without that DLL being present, the program fails to run.
What's the proper way of handling this situation?
Thank you
Your best bet would be to ditch the Windows Scripting Host completely. Here's a link to a method for creating shortcuts without relying on the WSH. It still uses COM though.
http://vbaccelerator.com/home/NET/Code/Libraries/Shell_Projects/Creating_and_Modifying_Shortcuts/article.asp
Here is a class that someone created that you can use:
http://www.msjogren.net/dotnet/eng/samples/dotnet_shelllink.asp
I have added a config file (myapp.exe.config) that is deployed to the device after installation. But the problem is that this file gets read-only attribute. I have tried adding some stuff in the setup project in "codeINSTALL_EXIT" function. On emulator it works ... it removes the read only attribute, while when installing on the phone the attribute stays.
SetFileAttributes(szPathConfig, FILE_ATTRIBUTE_NORMAL)
Any ideas?
It's not completely clear from your question how the file is getting deployed (though I think from a CAb only). Things to check/know:
If you install via CAB, but then deploy from Studio (i.e. Debug) the file will get overwritten and the file studio pushes may well be read-only, especially if your SCC mechanism locks local files that aren't checked out (like VSS does).
When you build a CAB file, the file attributes get inherited from the source, meaning that if the file is read-only on the PC when you create the CAB, it will be read-only coming out of the CAB. One woudl think that the EXIT of the installer would be late enough to alter the attributes, but I've never tested it. Following your current path, you might check that the attributes before setting and also check to see if the Set call is actually succeeding. Personally I'd just make sure all files were read/write enabled before building the CAB to avoid the whole problem in the first place.
On linux, we have LIBRARY_PATH and LD_LIBRARY_PATH environment variables in order for programs to search for libraries. Do we have similar thing on windows? Particularly Windows 7?
Also, I would like to know best practices for DLL use (where to put them, use envs or not, etc.), since I want to work on windows like everyone does, and not to sloth myself on workarounds :)
Edit: As explained by Bob, this answer describes the Alternate Search Order, which is not what most applications would see. The full rules are quite complex. I don't think I can summarize them here. Instead, read the Microsoft docs - https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
My original answer was:
This MSDN article explains the default search order. I quote:
The directory specified by lpFileName.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
In (1), if you statically linked against the DLL's stub library, I think "the directory specified by lpFileName" is the process's exe's path.
Take a look at the help for the LoadLibrary and CreateProcess functions. These describe the paths used to locate DLLs, and how you can modify them.
It looks on currentDir first then WinDir and SystemDir also in your path
According to what #andrew has mentioned in his answer, the order of folders that are used on Windows to search a DLL may be different from one configuration to another. I think the simplest way to check this order on Windows is to use the Dependency Walker tool. After opening the tool, and pressing the "Configure Module Search Order" button on the toolbar, you will see a window like this:
This window shows you the current search order on your machine. The interesting part is that by pressing "Expand", you can see the whole folders in the search path one by one. You may also change the order if you want, to be used for loading an specific module.