Re: Microsoft Windows LoadImage API Integer Buffer overflow
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@xxxxxxxxxxxxxxxx;flashsky@xxxxxxxxxx) 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