<<< Date Index >>>     <<< Thread Index >>>

[GOODFELLAS-VULN] FileFind class from MFC Library cause heap overflow



:. GOODFELLAS Security Research TEAM  .:
:. http://goodfellas.shellcode.com.ar .:


FileFind class from MFC Library cause heap overflow.
===================================================
Internal ID: VULWKU200706142


introduction
------------
The GOODFELLAS security research team has found a bug in the 
MFC42 and MFC71 libraries offered natively in Windows, specifically, 
the bug is in the FindFile class.

The said class is used to manage file searches accross the filesystem, 
it allows the user to specify the type of file his looking for.

The MFC Reference covers the classes, global functions, global
variables,
and macros that make up the Microsoft Foundation Class Library version 
8.0.

CFileFind Class=
http://msdn2.microsoft.com/en-us/library/f33e1618(VS.80).aspx
CFileFind::FindFile=http://msdn2.microsoft.com/en-us/library/x4dz98yx(VS.80).aspx

The MSDN documentation has no information related to bounds 
checking regarding to that function.


Summary
-------
The FindFile method allocates memory for the buffer[1]. 
The buffer then is used to store the contents of the first argument of 
the function[2] without cheching if the argument actually fits in the 
allocated buffer. This data is in turn used to start a search.

Both the unicode and ascii versions of the library use a very similar 
function and have the same bug, the only real difference is the size
of the allocated buffer. The unicode version allocates 592 bytes and, 
the ascii version, 320 bytes.


impact
------
Any application that uses the API, allowing the user to manipulate
its first argument, is vulnerable to this heap overflow.


workaround
----------
At the moment, there is no known workaround for the vulnerable software.
The function should internally use lstrcpynA or lsstrcpynW.


timeline
--------
june 14, 2007 -- bug discovery
june 20, 2007 -- notification to known affected ISVs
June 21, 2007 -- notification to microsoft
july 30, 2007 -- ping to microsoft
august 6, 2007 -- no properly answer (the bug is not so important)
august 31, 2007 -- we have asked for an schedule table
september 5, 2007 -- vendor response: "comming soon"
september 14, 2007 -- bug published


credits
-------
* Jonathan Sarba <sarbaj@xxxxxxxxxxxxxxxx>
* GoodFellas Security Research Team <goodfellas.shellcode.com.ar>


technical detail
----------------
MFC[42|71].dll@CFileFind::FindFile(char const *,unsigned long)
.text:73D6CD3F  mov     edi, edi
.text:73D6CD41  push    ebp
.text:73D6CD42  push    esi             ; unsigned int
.text:73D6CD43  push    edi             ; unsigned __int8 *
.text:73D6CD44  mov     esi, ecx
.text:73D6CD46  call    CFileFind::Close(void)
.text:73D6CD4B  push    140h                    ; int   << 320 bytes
.text:73D6CD50  call    @operator new(uint)             << buffer
Allocate [1]
.text:73D6CD55  mov     ebp, [esp+14h]
.text:73D6CD59  and     dword ptr [esi+10h], 0
.text:73D6CD5D  test    ebp, ebp
.text:73D6CD5F  pop     ecx
.text:73D6CD60  mov     [esi+8], eax
.text:73D6CD63  jnz     short loc_73D6CD6A
.text:73D6CD65  mov     ebp, offset a__1        ; "*.*" << si arg_0 ==
NULL
.text:73D6CD6A loc_73D6CD6A; CODE XREF: CFileFind::FindFile(char const
*,ulong)+24j
.text:73D6CD6A    push    ebp                           ; lpString2
.text:73D6CD6B    add     eax, 2Ch
.text:73D6CD6E    push    eax                           ; lpString1
.text:73D6CD6F    call    ds:__imp__lstrcpyA@8          ; lstrcpyA(x,x)
<< [2]
.text:73D6CD75    push    dword ptr [esi+8]             ; lpFindFileData
.text:73D6CD78    push    ebp                           ; lpFileName
.text:73D6CD79    call    ds:__imp__FindFirstFileA@8    ;
FindFirstFileA(x,x)
[...]

MFC[42|71]u.dll@CFileFind::FindFile(char const *,unsigned long)
.text:5F817BFC  push    ebx                     ; wchar_t
.text:5F817BFD  push    esi                     ; wchar_t *
.text:5F817BFE  push    edi
.text:5F817BFF  mov     esi, ecx
.text:5F817C01  call    CFileFind::Close(void)
.text:5F817C06  push    250h                    ; int   << 592 bytes
.text:5F817C0B  call    @operator new(uint)             << buffer
allocate [1]
.text:5F817C10  mov     ebx, [esp+14h]
.text:5F817C14  and     dword ptr [esi+10h], 0
.text:5F817C18  test    ebx, ebx
.text:5F817C1A  pop     ecx
.text:5F817C1B  mov     [esi+8], eax
.text:5F817C1E  jnz     short loc_5F817C25
.text:5F817C20  mov     ebx, offset a_          ; "*.*" << si arg_0 ==
NULL
.text:5F817C25 loc_5F817C25; CODE XREF: CFileFind::FindFile(ushort const
*,ulong)+22j
.text:5F817C25    push    ebx                           ; lpString2
.text:5F817C26    add     eax, 2Ch
.text:5F817C29    push    eax                           ; lpString1
.text:5F817C2A    call    ds:__imp__lstrcpyW@8          ; lstrcpyW(x,x)
<< [2]
.text:5F817C30    push    dword ptr [esi+8]             ; lpFindFileData
.text:5F817C33    push    ebx                           ; lpFileName
.text:5F817C34    call    ds:__imp__FindFirstFileW@8    ;
FindFirstFileW(x,x)
[...]

-- 
GOODFELLAS (Shellcode Security Research)
http://goodfellas.shellcode.com.ar

Attachment: signature.asc
Description: This is a digitally signed message part