| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 14 Sep 2007 13:16:42 -0300
From: GOODFELLAS SRT <goodfellas@...llcode.com.ar>
To: bugtraq-post <bugtraq@...urityfocus.com>,
full-post <full-disclosure@...ts.grok.org.uk>
Subject: [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@...llcode.com.ar>
* GoodFellas Security Research Team <goodfellas.shellcode.com.ar>
technical detail
----------------
MFC[42|71].dll@...leFind::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@...leFind::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
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists