Microsoft LNK Vulnerability Brief Technical Analysis (CV

For the first poor translation, I would like to thank google translation and youdao Dictionary (word translation ), this vulnerability is triggered because when the CPL icon is loaded using a specially constructed shortcut, the dll file will be loaded directly through the "LoadLibraryW" function (originally, the file resources were only intended to be loaded but not judged ). whether the dll file is a special CPL file, as a result, malicious dll files are directly loaded. This causes the user to trigger the vulnerability when using the resource manager browser. In fact, this is a design defect of Microsoft and does not properly check the file security.

PS: It seems that the PIF file is also affected in the Microsoft Security announcement.

Source article: aspx "> http://community.websense.com/blogs/securitylabs/archive/2010/07/20/microsoft-lnk-vulnerability-brief-technical-analysis-cve-2010-2568.aspx

A few days ago, an exploit used for highly targeted attacks was published here: CVE-2010-2568 Lnk shortcut. as the blog post, and other posts, state, this is caused by Windows Control Panels shortcut cut image display routine. the original blog post shows a stack trace of the exploit results, which also serves to explain the vulnerability.

A few days ago, a high-risk vulnerability released: CVE-2010-2568 (shortcut) vulnerability, we discuss in the blog, pointed out that the cause of this vulnerability is windows Control Panel shortcut picture display routines. The first blog published showed the result of stack tracking for vulnerability execution, and explained the vulnerability trigger principle.

The nature of the vulnerability is pretty clear. but out of curiosity we did some reverse engineering and here is what we have found. the bug itself is a design flaw as stated by Province people and its very straightforward to locate the point where it happens. the vulnerable file is shell32.dll and the vulnerable routines are Control Panel-related. we loaded the binary on a discycler and found that the Control Panel file-related routines start with a "CPL _" prefix.

The principle of this vulnerability is very clear. But in curiosity, we have done a lot of reverse engineering. The following is what we found. This vulnerability is a design defect as everyone said. It is very simple to find the location where the problem occurs. The files with threats are shell32.dll and related routines of the Control Panel files with threats. We loaded binary files for decompilation and found that the routines related to Control Panel files are prefixed with "CPL.

Drawing 1 shows the relations between CPL initialization routines and data flow. The red "LoadLibraryW" API is the vulnerable one

Figure 1 shows the CPL initialization routine and data flow. The red-labeled "LoadLibraryW" function is the key to triggering the vulnerability.

 

Figure 1: Program Execution Process and data flow

The icon extraction routine CILS "CPL_FindCPLInfo" to find the icon information of the target file. the "CPL_FindCPLInfo" routine is basically a wrapper around und all CPL-related routines. the loading and initialization of the CPL module is already med before getting any information out of it. one of the initialization routines, "_ LoadCPLModule", callthe "LoadLibraryW" API to load the target CPL dll for future use. the module handle acquired from this call is used later in the "_ InitializeControl" routine with the "LoadImage" API. there are ways to acquire an icon handle from a dll without loading it, but in this case the programmer chose to load the target dll for some reason, which opens the vulnerability.

ICO obtains the ICO information of the Target Program by executing the "CPL_FindCPLInfo" function. The "CPL_FindCPLInfo" routine is the encapsulation of all CPL-related routines. The CPL module obtains all CPL information through this routine before it is loaded and initialized. One of the initialization routines "_ LoadCPLModule" calls "LoadLibraryW" to load the target CPL (CPL is actually a special dll file) for later use. The handle returned after the "LoadLibraryW" function is called will be used by the "_ InitializeControl" routine and the "LoadImage" function. In this way, you can obtain the icon handle of the dll file and do not need to load it. However, in special circumstances, the programmer chooses to directly load a malicious target DLL.

It looks like the security side-effects of one module are not evaluated fully before its combined with other modules.

This seems that this component was not fully evaluated before it worked with other modules.

We recommend following this Microsoft security advisory to disable icon display or the WebClient service until a patch for this flaw is released.

We recommend that you prohibit ICO from displaying or disabling the WebClient Service as described in the Microsoft Security Bulletin to know that Microsoft has released a patch to fix this vulnerability.