Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Windows :: hack7647.htm

Microsoft Windows LoadImage API Integer Buffer overflow
Microsoft Windows LoadImage API Integer Buffer overflow

[Security Advisory]



Advisory: [AD_LAB-04004]Microsoft Windows LoadImage API Integer Buffer overflow

Class: Boundary Condition Error


Remote: Yes



 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






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.





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 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 





Flashsky(; discovery this vuln:)

Vulnerability analysis and advisory by Flashsky and icbm.

Special thanks to "Fengshou" project members and all Venustech AD-Lab guys:P





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 




Trusted  {Solution} Provider


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH