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@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."
