bugtraq - Re: Microsoft Windows LoadImage API Integer Buffer overflow

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6.2.0.14.2.20041224171730.05a0e780@localhost>
Date: Fri, 24 Dec 2004 17:18:56 -0700
From: Brett Glass <brett@...iat.org>
To: flashsky fangxing <flashsky@...cus.org>,
	bugtraq@...urityfocus.com
Subject: 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@...ustech.com.cn;flashsky@...cus.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