Conceptual vulnerability in the DLL loading mechanism (MSA2269637)

Last week, Habré already wrote about the HD Moore application and the vulnerability it found, which is contained in a fairly large number of applications and works on all versions of MS Windows. But everything turned out to be much more serious, since it is not just a vulnerability that was found, but a conceptual error in the design of the dynamic library loading mechanism. On this occasion, Microsoft officially released Security Advisory (2269637) yesterday , which means official recognition of the seriousness of this vulnerability. But let's try to understand the essence of this problem, since it is no less serious than the recently discovered vulnerability in downloading LNK files .

The vulnerability lies in the fact that many programs, when calling the LoadLibrary () function, do not check the correctness of the way in which this library can be loaded. Thus, they allow the substitution of the executed library. This is due to the fact that the search for the loaded library is carried out primarily in the directory containing the image of the executable file that spawned the process (the replaced library is performed with the privileges of the user who started the process). For example, Georgi Guninski offered the following demonstration (PoC) of this vulnerability:

1) Compile the code he developed as a dynamic library
2) Rename the resulting library to riched20.dll and place it in any directory of your choice
3) Check if there are any open applications from MS Office. And if there is, then close them.
4) Open an MS Word document by double-clicking on it from Windows Explorer in the directory where our riched20.dll was placed
')
By and large, this kind of application vulnerability is not a new trend, and they have been known for a long time. For example, David LeBlanc wrote about this problem ( “DLL Preloading Attacks” ) back in 2008. Another thing is that the problem still exists and the number of applications that are vulnerable in this way is still very large. The most terrible and striking thing is that the substitution can be done not only to a locally located DLL, but also to load a remotely located library. An example to demonstrate this possibility was a vulnerability for iTunes , which, when opening media files from network resources, could load dynamic libraries from the same network storage. For successful operation, you only need to form an SMB or WebDAV path (for example, the following: \\ server \ movies \) to a network resource, and so that when you run the file, the dynamic library that we want to run is located in the same directory. To conduct attacks of this kind, a universal exploit has already been implemented as part of the Metasploit project (an example of use is described here ).

Now let's talk about what to do about it and how to avoid it in our programs. Most likely, it will take a lot of time for developers to close this vulnerability, because the vulnerability is contained in the architecture of the mechanism for executing dynamic libraries. And it will not be so easy to close it without affecting the performance of the existing software. So, firstly, there is an implementation of the SafeLoadLibrary () function from David LeBlanc and MS’s best practices :

HMODULE SafeLoadLibrary(const wchar_t* wzFileName)
{
static wchar_t wzSystem[MAX_PATH];
wchar_t wzCurDir[MAX_PATH];
HMODULE hMod = NULL;
if(wzSystem[0] == L'\0')
{
if(GetSystemDirectory(wzSystem, _countof(wzSystem)) == 0)
return NULL;
}

// Now get the actual current working directory
if(GetCurrentDirectory(_countof(wzCurDir), wzCurDir) == 0)
wzCurDir[0] = L'\0';
SetCurrentDirectory(wzSystem);
hMod = LoadLibrary(wzFileName);
SetCurrentDirectory(wzCurDir);
return hMod;
}

There is also a DLL utility Hijacking Audit Tool, created by Rapid7 / HDmoore, to search for vulnerable applications and recommendations from MS.