[33948] in bugtraq

home help back first fref pref prev next nref lref last post

RE: Windows XP explorer.exe heap overflow.

daemon@ATHENA.MIT.EDU (Larry Seltzer)
Wed Feb 25 15:55:21 2004

From: "Larry Seltzer" <larry@larryseltzer.com>
To: "'Eli K.'" <elik@beyondsecurity.com>, <sunglasses@bay-watch.com>,
        <bugtraq@securityfocus.com>
Date: Wed, 25 Feb 2004 10:48:31 -0500
Message-ID: <010901c3fbb6$e0238630$5b00005a@moregarlic.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <200402241236.12942.elik@beyondsecurity.com>

The sample someone sent around that caused the 100% CPU hogging had the Size field set
to 0000h. Try that. Perhaps it's not just a matter of the value being lower, but below
some small threshold.

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
larryseltzer@ziffdavis.com 

-----Original Message-----
From: Eli K. [mailto:elik@beyondsecurity.com] 
Sent: Tuesday, February 24, 2004 5:36 AM
To: sunglasses@bay-watch.com; bugtraq@securityfocus.com
Subject: Re: Windows XP explorer.exe heap overflow.


I have tried to verify this issue with a malformed EMF file. Either I didn't 
understand something or the vulnerability doesn't exist.

Here's what I did:

I took a sample EMF file and modified it's Size field (offset 0030h) to some smaller
value such as 0020h. The reported header size (offset 04h) 
was 0000006Ch. I've experimented with the values a little but to no avail.

Windows XP seems to be immune to this. I didn't see any point on trying a different OS
(such as Win2K).

Maybe the poster to the list can provide some details or a malformed EMF file so we
could verify the issue ?

Eli

On Friday 20 February 2004 20:45, sunglasses@bay-watch.com wrote:
> Vulnerability in XP explorer.exe image loading
> ----------------------------------------------
>
> Systems affected:
>   Current XP - others not tested.
>
> Degree:
>   Arbitrary code execution.
>
> Summary
> -------
> A malformed .emf (Enhanced Metafile, a graphics format) file can cause 
> an exploitable heap overflow in (or near) shimgvw.dll.
>
> Details
> -------
> The image preview code that explorer uses has an exploitable buffer 
> overflow.
>
> An .emf file with a "total size" field set to less than the header 
> size will causes explorer.exe to crash in the heap routines - in 
> classic heap overflow style that should be exploitable a la the RPC 
> exploits.
>
> There are two overflows here:
>
> 1. A buffer is allocated with the size indicated in the header (no 
> validity checks), then the header is copied into it - if the size is 
> less than the header size, that's one overflow.
>
> 2. They then proceed to read the rest of the file to a length of 
> (size-headersize), which allows for an integer overflow causing the 
> rest of the file to be appended to the already blown buffer.
>
> Exploit
> -------
> To exploit this flaw (in explorer), simply place a malformed (invalid 
> "size" field) .emf file in any directory, open explorer to that path, 
> and view as Thumbnails. Bang. In it's simplest form it's a DOS - it 
> affects all explorer windows, including File Open dialogs for many 
> programs.
>
> Alternatively, without viewing as a Thumbnail, open the picture 
> preview window for the .emf file. (It's the default double-click 
> action). Using this trigger causes a different crash point, which may 
> not be exploitable, but I wouldn't rule it out.
>
> Additional notes
> ----------------
> It may be worth checking out similar issues in .wmf files, as they are 
> similar.
>
>
> - Jellytop, 2004
>
> "If a man will begin with certainties, he shall end in doubts; but if 
> he will be content to begin with doubts he shall end in certainties."




home help back first fref pref prev next nref lref last post