鬼仔's Blog

鬼仔注：在cnbeta上看到了这个新闻，前半部分新闻部分是在cnbeta转来的，后面的英文部分是SecLists上的相关信息。

cnbeta：
来自US CERT的警报,微软Windows操作系统的重要组件API:MFC42,MFC71中包含0day漏洞.
该漏洞出现在"FindFile"功能的用户输入长度验证中,可以导致缓冲区溢出,并允许执行任意代码.
由于MFC42是许多Win32程序编程不可缺少的组件,大量程序需要调用到这两个API,因此这一问题相当严重.

目前已知可能导致漏洞的应用程序有,HP Photo & Imaging Gallery 1.1 与 v2.1软件包,它包含在惠普全功能打印机驱动程序中.

据了解,该问题早在今年6月就被发现并上报,但微软一直没有回应,导致了今日0day漏洞的出现.

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

From: GOODFELLAS SRT <goodfellas_at_shellcode.com.ar>
Date: Fri, 14 Sep 2007 13:16:42 -0300

:. 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_at_shellcode.com.ar>
* GoodFellas Security Research Team <goodfellas.shellcode.com.ar>

technical detail
—————-
MFC[42|71].dll_at_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_at_8 ; lstrcpyA(x,x)
<< [2]
.text:73D6CD75 push dword ptr [esi+8] ; lpFindFileData
.text:73D6CD78 push ebp ; lpFileName
.text:73D6CD79 call ds:__imp__FindFirstFileA_at_8 ;
FindFirstFileA(x,x)
[…]

MFC[42|71]u.dll_at_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_at_8 ; lstrcpyW(x,x)
<< [2]
.text:5F817C30 push dword ptr [esi+8] ; lpFindFileData
.text:5F817C33 push ebx ; lpFileName
.text:5F817C34 call ds:__imp__FindFirstFileW_at_8 ;
FindFirstFileW(x,x)
[…]

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