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