DLL hijacking vulnerability caused by static links of Dynamic Link Libraries-description using QQ program xgraphic32.dll

DLL hijacking vulnerability caused by static links of Dynamic Link Libraries

Description using QQ program xgraphic32.dll

 

I don't want to say so much about it. Open the question directly.

 

I. Database

First, let's clarify the concept of the Library. The library stores binary encoding. Looking at the development path of programming technology, we can see a clear development context: code> static library> dynamic library.

Assume that we want to compile a program called calc.exe, but now there is a ready-made library that stores compiled functions such as add (), sub (), and other related symbols, and the static library (calcfun. lib) and dynamic library (calcfun. DLL) each has a version.

Then, we only need to encode the main program of calc.exe, and use the functions in the Library (you can export the function class constants and wait for these functions to be collectively referred to as symbols) without coding these functions.

A. Use a static library

The static library has only one lib file calcfun. Lib (ignore the export function declaration calcfun. h file). This lib file contains binary encoding. Slave can run (the Library required by the operating system is ignored here ).

B. Use a dynamic library

The standard dynamic library generally has two files: calcfun. DLL, calcfun. lib (ignore the export function declaration calcfun. h file), do not confuse this lib file with the above static library lib file. The correct name of this lib file is imported to the import database, including the address table of the exported symbols in the DLL, it is only provided to the linker to locate the symbols in the DLL. It is not binary code. The real binary code exists in calcfun. DLL. Why are there two files? Because there are two ways to use the Dynamic Link Library: static Link (implicit link) and dynamic link (display link ).

1) Static Link (implicit link)

Required depends on calcfun. DLL to run properly. Compile, you can also use the pre-compiled processing: # pragma comment (Lib,
"Calcfun. lib ")

2) Dynamic Link (display link)

This method requires only one DLL file, and the Lib file is redundant, because the DLL itself also contains the address table of its own exported symbols, so we only need to load this DLL into the address space of our program, and then find the address of the function or other symbols we need. This method does not generate information to the PE Header of calc.exe. The generated calc.exe must depend on calcfun. DLL to be correctly cleared. The implementation of this link method is to load the DLL module through loadlibrary (), find the target symbol address through getprocessaddress (), and uninstall the DLL module through freelibrary.

3) loading time

In addition to using different dynamic libraries, there is also the time to load them. Compilation is done by us, and all the work in the runtime is done by the operating system. The import table of the PE Header in the EXE generated by the static Link contains the required DLL information, so the program loader reads the import table and loads all the DLL files in the import table (except for delayed loading, this article does not discuss ). The dynamic link library loads the specified DLL only when the program calls the loadlibrary () function.

Static databases are not common in dynamic libraries. Therefore, dynamic link libraries are commonly used in windwos operating systems. As you can see from the above introduction, the process space in which the DLL is finally loaded into the program is completed by the operating system. How does the operating system know the location of the required DLL? Obviously, the operating system needs a set of Search rules to load dynamic link libraries.

 

Ii. Search sequence of dynamic link library (DLL)

The program can control where to load the DLL by specifying the full path or using a list mechanism. If these methods are not used, the system will perform a DLL search.

 

A. elements that affect search

1. if a DLL with the same name has been added to the memory, the system will only check the redirection and list before parsing the DLL to be loaded, no matter which directory the DLL is located, that is to say, the system will not search for DLL.

2. If the DLL required by a program exists in the known DLLs list of the local machine, the system will directly use the known DLL instead of searching for the DLL. Path of the know DLLs list of the current system in the Registry: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ sessionmanager \ knowndlls

3. if a DLL (such as. DLL) depends on other DLL (such as B. DLL, C. DLL), the system will only search for the dependent DLL (B. DLL, C. DLL ...), even if the first DLL (. DLL) is loaded through the full path, this rule also applies.

 

B. Standard search order

The system has a set of standard DLL search path rules, which are divided into two search modes: safe search mode and non-secure search mode. The security search mode is enabled by default. to disable the security search mode, you can createHKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ sessionmanager\SafeDllSearchModeAnd set the value to 0.

1. Security search mode Sequence

> 1.exe program directory

> 2. Obtain the system directory (getsystemdirectory)

> 3.16-bit system directory

> 4. Windows Directory

> 5. Current process directory

> 6. directory in the System Path Environment Variable

 

2. Non-Secure Search Mode

> 1.exe program directory

> 2. Current process directory

> 3. Obtain the system directory (getsystemdirectory)

> 4.16-bit system directory

> 5. Windows directory.

> 6. directory in the System Path Environment Variable

 

All Dynamic Link Libraries connected through static links follow the above a. B search sequence rules.

 

C. Use loadlibrary (maid) or LoadLibraryEx (maid ,...) The dynamic link of function implementation has the following rules.

1. lpfilename contains the file path + file name

Search for the file in the specified path first. If the file exists, the function returns success. If the file does not exist, the function returns failure.

2. lpfilename does not contain the file path + file name

Instead, the function uses the standard search path of the system.

 

For more details about the search order of the dynamic link library, see http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx

 

Iii. dll hijacking vulnerability in QQ Program

This vulnerability is a vulnerability that has existed since qq2009. The vulnerability is caused by the introduction of QQ's Interface Engine GF. dll.

Let's take a look at the msimg32.dll file. This file is a library of Windows GDI Function Clusters, with only four functions.

 

It exists in the system directory c: \ windows \ system32 \ msimg32.dll.

When we use dependency walker1_qq.exe to start, the DLL dependency exists:

 

Qq.exe-> GF. dll-> xgraphic32.dll-> msimg32.dl.

It may be said that the display of msimg32 has been loaded from the arrow icon. It is normal to have this question. We can see another dependency chain: qq.exe-> user32.dll-> msimg32.dl.

At first glance, there is no problem. There is no possibility of hijacking: there is a rule that Windows reads the EXE import table during loading and then loads the dependency module, But no matter the order of the import table, as long as the DLL in the import table exists in the knows DLL list, the system will give priority to these modules. user32.dll must exist in the knows DLL list, so user32.dll must be prior to GF. in this way, the system will directly load user32.dll under the system directory, and user32.dll will load msimg32.dll (that is, the original msimg32.dll of the system) from its own directory ), then, the loaded GF-> xgraphic32.dll-> msimg32.dll will directly return the previously loaded block handle, so that there is no possibility of msimg32.dll hijacking.

However, you should see that the icon in front of msimg32.dll in user32.dll is delayed loading! Only qq.exe does not call any function exported from msimg32.dll before loading xgraphic32.dll. Therefore, the first time msimg32.dll is loaded, it should be in xgraphic32.dll. So what is the QQ program? We can use process monitor to verify it!

Set filter options for Process Monitor. Then start QQ. exe

After the logon window is displayed after QQ is started, check the "File Operation" Capture result and search for msimg32

We found that the first loading was indeed in xgraphic32.dll!

Truth: The first time msimg32.dll is loaded in QQ. EXE, it is in a non-system module, and msimg32.dll is not listed as knowndlls by Microsoft. Therefore, if a third-party software developer implements a module and statically links msimg32.dll to the module, a vulnerability is left that allows the system to search for DLL sequence for DLL hijacking. Unfortunately, the GF dependency module xgraphic32.dll is such a module.

When xgraphic32.dlldepends on msimg32.dll, the system first searches for the directory where qq.exe is located. If it does not exist, the system searches for the original msimg32.dll in the system directory according to the rules. However, if someone passes the dllpilot to export a signed transmitter, what will happen if a fake msimg32.dllis placed in the qq.exe directory? Worker Process space, while the dllmain of msimg32.dll can do anything you want to do. It is no small harm to destroy the QQ program. If it is used as a virus, Trojan, or backdoor, the problem is not serious.

Solution:

1. We can see that xgraphic32.dll only uses the alphablend function exported by msimg32.dll, so we can try to implement it by ourselves. However, this solution is not feasible based on efficiency.

2. Rewrite xgraphic32.dll and use an explicit dynamic link to specify the full path. This seems to be the best solution for the moment.

3. let Microsoft add msimg32.dll to the known DLLs list. This is the most perfect solution, but we need to communicate with Microsoft. We hope this idea will be realized next time we see the system's SP patch package.

4. Add a token and check whether the msimg32.dll file exists in the current directory in qq.exe. If the file exists, an error is returned. If the file does not exist, it is started normally. Although this statement is stupid, it is actually a very effective statement. However, if qq.exe is reversed, it will still be able to continue hijacking if it finds and modifies the code segment. However, it will take legal risk responsibility to do so.

 

Iv. Supplementary topic: DLL hijacking

You can review the useful ws2_32.dll that once became the best object for DLL hijacking. Microsoft did not list it as known DLLs. Although there are many functions in this DLL, however, if you want to perform hijacking, you only need to forward the function introduced by the target exe. However, not all programs need to call this dynamic link library because it is a module of the Windows Socket function cluster. But msimg is different, because user32.dll also references this function, so if all functions are not forwarded, it may cause an error. Fortunately, msimg32.dll only has four functions, it can be completely forwarded without any effort, but this is precisely the cause of a serious vulnerability.

 

I wanted to paste a piece of forged msimg32.dll to call the QQ-encapsulated MessageBox routine, but I still did not do it for security reasons.