[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200402251827.01410.elik@beyondsecurity.com>
Date: Wed, 25 Feb 2004 18:27:01 +0200
From: Eli Kara <elik@...ondsecurity.com>
To: "Larry Seltzer" <larry@...ryseltzer.com>,
<sunglasses@...-watch.com>, <bugtraq@...urityfocus.com>
Subject: Re: Windows XP explorer.exe heap overflow.
The author spoke of a heap-based overflow (which we know can lead to code
execution).
Although peaking the CPU at 100% shouldn't happen, it is still quite different
than an overflow :)
E
On Wednesday 25 February 2004 17:48, Larry Seltzer wrote:
> 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@...fdavis.com
>
> -----Original Message-----
> From: Eli K. [mailto:elik@...ondsecurity.com]
> Sent: Tuesday, February 24, 2004 5:36 AM
> To: sunglasses@...-watch.com; bugtraq@...urityfocus.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@...-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."
Powered by blists - more mailing lists