Analysis of Microsoft CFileFind: FindFile function Overflow Vulnerability

Text/Graph
==========================================
The news about this vulnerability has been coming out for some time. When I heard this news, I still don't know it. I only know that Microsoft's important API has a vulnerability in cloud. In fact, if we want to know more about these vulnerabilities, we still need to rely on your sensitivity to the information and a wider range of information sources. In any case, I search for these vulnerabilities, in the so-called "First time", I learned the specific problem. It turns out that a function in MFC has an error. Specifically, it refers to the FindFile function in the CFileFind class. I really admire these bugs-hunter, this is a true portrayal of the cool. When talking about this vulnerability, it is actually not easy to use. I will analyze the specific problem for a while. If I want to use it in combination with the context environment of the software, I have never seen any separate exploit, but just as the explosion of the same vulnerability, this function is an important function of Microsoft and has a wide impact. Almost all software written using MFC will be affected. Next I will take you to repeat the vulnerability discovery process, so that these cainiao can also experience the extraordinary realm of vulnerability research.
Assume that X is less than or equal to 7 on a certain day in X, because the vulnerability is a thing of the past. You are sitting in front of your computer and using VC6.0 to write a program for file traversal, one section is designed to traverse a folder to obtain the file name. Based on your experience, you can choose to write the SDK or MFC. It seems that the simplicity of MFC makes you more inclined to it, so I wrote the following code.

CFileFind ff;
SetCurrentDirectory ("C: \ test ");
If (ff.findfile( .txt ", 0) MessageBox (" OK ");

It looks very simple. With three lines of code, you can query the "c: est”" folder and find the file" example. txt ". Finally, you want the user to pass a custom Query file name parameter to the FindFile function. If the file name passed by the user exceeds 260 bytes, can MFC find this error? Does its convenience bring us some negative effects? With a bit of doubt, you modified the Code to make it look like this.

Char fs [261] = "";
// Note that a 261-byte parameter is passed to FileFind.
CFileFind ff;
SetCurrentDirectory ("C: \ test ");
If (ff. FindFile (fs, 0) MessageBox ("OK ");

Compile and run, bang! A big error is displayed! 1. It is hard to say that our MFC has not noticed this obvious error? Unfortunately, this is indeed the case. The MFC encapsulation is indeed not rigorous enough. How did it happen? You are used to reverse technology to find the answer. Okay, now IDA is used to reverse the implementation process of the FindFile function of MFC.

Figure 1
Several minutes later, IDA will show you the entire process of FindFile function implementation, as shown in figure 2. With the help of the powerful IDA, you will find that this is a very good analytical operation process, you can almost write the FindFile function implementation source code according to the analysis provided by IDA. Then you begin to write down the following implementation code.

Figure 2

Int CFindFile: FindFile (LPCSTR lpFileName, int)
{
Close ();
WIN32_FIND_DATA f;
If (lpFileName = NULL) lpFileName = "*.*";
Lstrcpy (f. cFileName, lpFileName );
// Note that this function directly transmits parameters without any boundary check. A typical overflow error occurs.
HANDLE temp = FindFirstFile (lpFileName, & f );
......
}

Here you suddenly find a problem. For the WIN32_FIND_DATA structure, its prototype is:

Typedef struct _ WIN32_FIND_DATAA {
DWORD dwFileAttributes;
FILETIME ftCreationTime;
FILETIME ftLastAccessTime;
FILETIME ftLastWriteTime;
DWORD nFileSizeHigh;
DWORD nFileSizeLow;
DWORD dwReserved0;
DWORD dwReserved1;
CHAR cFileName [MAX_PATH];
CHAR cAlternateFileName [14];
# Ifdef _ MAC
DWORD dwFileType;
DWORD dwCreatorType;
WORD wFinderFlags;
# Endif
}

Pay attention to the cFileName parameter. The allocation space of this value is only 260 bytes. However, the encapsulated FindFile function uses an Lstrcpy (f. cFileName, lpFileName); without any border check, the lpFileName parameter is copied to the cFileName parameter in the WIN32_FIND_DATAA structure in a abrupt manner. Based on the results of disassembly, this is easy to understand, and the lpFileName parameter is a parameter that is randomly transmitted by the user. Does MFC implement the internal transmission process of the parameter in this way? It's not surprising that the program will go wrong.
After talking about the reverse research method, you 'd better see the true implementation of CFileFind: FileFind. It is very simple. The file contained in VC6.0 has a specific implementation. Let's take a look at its actual code.

BOOL CFileFind: FindFile (LPCTSTR pstrName/* = NULL */,
DWORD dwUnused/* = 0 */)
{
UNUSED_ALWAYS (dwUnused );
Close ();
M_pNextInfo = new WIN32_FIND_DATA;
M_bGotLast = FALSE;
If (pstrName = NULL)
PstrName = _ T ("*.*");
Lstrcpy (WIN32_FIND_DATA *) m_pNextInfo)-> cFileName, pstrName );
M_hContext =: FindFirstFile (pstrName, (WIN32_FIND_DATA *) m_pNextInfo );
If (m_hContext = INVALID_HANDLE_VALUE)
{
DWORD dwTemp =: GetLastError ();
Close ();
: SetLastError (dwTemp );
Return FALSE;
}
......

Here I only posted a key piece of implementation code, and we can see that this is almost the same as our reverse results. The appearance of the problem is indeed not rigorous in the use of the lstrcpy function. After static analysis, you will say this should be easy to use. Otherwise, you must track it dynamically to let us know exactly what the program did when an error occurred. Take out OD and hook up the overflow test code program you just wrote. In mfc42d, The lstrcpy function call starts and ends with a breakpoint. Note that, after the program enters the lstrcpy with an error for overwriting overflow, it goes to the next function FindFirstFile. In this case, the FindFirstFile function cannot find files, so the program naturally enters the "if (m_hContext = INVALID_HANDLE_VALUE)" statement, and then comes to Close ();. Pay attention to this function. You have a little programming experience, as you can guess, the goal is to destroy the existing handles and allocated memory. Its implementation is as follows.
Void CFileFind: Close ()
{If (m_pFoundInfo! = NULL)
{
Delete m_pFoundInfo;
M_pFoundInfo = NULL;
}
If (m_pNextInfo! = NULL)
{
Delete m_pNextInfo; // pay attention to this object
M_pNextInfo = NULL;
}
If (m_hContext! = NULL & m_hContext! = INVALID_HANDLE_VALUE)
{
CloseContext ();
M_hContext = NULL;
}}
In the dynamic tracking, you will find that an error occurs when the m_pNextInfo object is destroyed. In the implementation of filefind, m_pNextInfo is a WIN32_FIND_DATA object allocated on the stack. Note that this statement "m_pNextInfo = new WIN32_FIND_DATA" is not strictly used by the lstrcpy function, as a result, the heap structure is abnormal, and a linked list error occurs when the heap is released, resulting in a program exception, as shown in 3. Note that the edx register has been modified, pointing to a memory violation. For such a stack release error, it is difficult for us to accurately think about the method of exploits. Therefore, we need to combine the context environment where the program runs to further analyze and utilize the issue. Of course, this is just my idea. If you can do it, please do not hesitate to give me some advice.

Figure 3
Now, you have made a self-discovery journey of a vulnerability. In general, this vulnerability is simple, but it requires an opportunity to take advantage of it. It is said that some of HP's products have been affected by this, and I have not explored it. If you are interested, you can test it on your own.