Conceptual Vulnerability in DLL Load Engine (MSA2269637)

    Last week, on Habré, they wrote about the statement of HD Moore 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 about the vulnerability found, but about a conceptual error in the design of the mechanism for loading dynamic libraries. In this regard, yesterday Microsoft officially released Security Advisory (2269637) , which means the 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 found vulnerability in loading LNK files .

    The vulnerability is that many programs when calling the LoadLibrary () functionDo not check the correctness of the way in which this library can be loaded. Thus, they allow the substitution of an executable 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 generated the process (the replaced library is run with the privileges of the user who launched the process). For example, Georgi Guninski proposed the following demonstration (PoC) of this vulnerability:

    1) Compile the code he developed as a dynamic library
    2) Rename the resulting library into riched20.dll and place it in any directory of your choice
    3) Check if there are open applications from the MS Office suite. And if so, then close them
    4) Open the 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 were already known long. 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 worst and most amazing thing is that the substitution can be made not only to a locally located DLL, but also to load a remotely located library. An example to demonstrate this feature was the 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 create an SMB or WebDAV path (for example, this: \\ server \ movies \) to a network resource, and so that when you start the file, the dynamic library that we want to execute was located in the same directory. To carry out 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 with this and how to avoid this 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 dynamic library execution engine. And shutting it down without affecting the performance of existing software will not be so easy. So, firstly, there is an implementation of the SafeLoadLibrary () function from David LeBlanc and best practices from MS: There is also a Hijacking Audit Tool DLL utility created by Rapid7 / HDmoore to search for vulnerable applications and recommendations from MS.

    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;
    }



    Also popular now: