Since it's highly unlikely that Microsoft will handle this bug in a timely
manner,
and highly likely that malicious parties will do so over the Christmas weekend,
does anyone know how best to write a shim to defuse this vulnerability?
--Brett
At 07:58 AM 12/23/2004, flashsky fangxing wrote:
[Security Advisory]
Advisory: [AD_LAB-04004]Microsoft Windows LoadImage API Integer Buffer overflow
Class: Boundary Condition Error
DATE:12/20/2004
Remote: Yes
Vulnerable:
Windows NT
Windows 2000 SP0
Windows 2000 SP1
Windows 2000 SP2
Windows 2000 SP3
Windows 2000 SP4
Windows XP SP0
Windows XP SP1
Windows 2003
not vulnerable:
No one knows:P
Vendor:
www.microsoft.com
I.DESCRIPTION:
-------------
An exploitable integer buffer overflow exists in the LoadImage API of the
USER32 Lib. This
function loads an icon, a cursor or a bitmap and then try to proceed the
image. If an attacker
sends a specially crafter bmp, cur, ico or ani file within an HTML page or in
an Email, it is
then possible to run arbitrary code on the affected system.
II.DETAILS:
----------
When the LoadImage API try to proceed the image, it directly uses the size
field in the image
file and then add 4. So if we set the size of image between
0xfffffffc-0xffffffff, an integer buffer
overflow occurs.
The function defines:
HANDLE LoadImage(
HINSTANCE hinst, // handle of the instance containing the image
LPCTSTR lpszName, // name or identifier of the image
UINT uType, // type of image
int cxDesired, // desired width
int cyDesired, // desired height
UINT fuLoad // load flags
);
lpszName is the handle to the image to load, uType specifies the type of image
to be loaded.
This parameter can be one of the following values:
IMAGE_BITMAP Loads a bitmap.
IMAGE_CURSOR Loads a cursor.
IMAGE_ICON Loads an icon.
When LoadImage API try to parse the bmp,cur,ico,ani file format, it doesn't
implement any check
on the size field and add 4. Look at the code below:
When use ANI or CUR:
.text:77D56178 mov eax, [ebx+8]
//Direct read our size here:P
.text:77D5617B mov [ebp+dwResSize], eax
.text:77D5617E jnz short loc_77D56184
.text:77D56180 add [ebp+dwResSize], 4 //add 4
int overflow...
.text:77D56184
.text:77D56184 loc_77D56184: ; CODE XREF:
sub_77D5608F+EFj
.text:77D56184 push [ebp+dwResSize]
//allocate a wrong size
.text:77D56187 push 0
.text:77D56189 push dword_77D5F1A0
.text:77D5618F call ds:RtlAllocateHeap
Then use the fake size for memmov and lead the heap overflow:
.text:77D561A9 mov ecx, [ebx+8]
.text:77D561AC mov esi, [ebx+0Ch]
.text:77D561AF add esi, [ebp+arg_0]
.text:77D561B2 mov edx, ecx
.text:77D561B4 shr ecx, 2
.text:77D561B7 mov edi, eax
.text:77D561B9 rep movsd
.text:77D561BB mov ecx, edx
.text:77D561BD and ecx, 3
.text:77D561C0 rep movsb
More details and POC at http://www.xfocus.net/flashsky/icoExp/index.html
III.CREDIT:
----------
Flashsky(fangxing@venustech.com.cn;flashsky@xfocus.org) discovery this vuln:)
Vulnerability analysis and advisory by Flashsky and icbm.
Special thanks to "Fengshou" project members and all Venustech AD-Lab guys:P
V.DISCLAIMER:
------------
The information in this bulletin is provided "AS IS" without warranty of any
kind. In no event shall we be liable for any damages whatsoever including
direct,
indirect, incidental, consequential, loss of business profits or special
damages.
Copyright 1996-2004 VENUSTECH. All Rights Reserved. Terms of use.
VENUSTECH Security Lab
VENUSTECH INFORMATION TECHNOLOGY CO.,LTD(http://www.venustech.com.cn)
Security
Trusted {Solution} Provider
Service
