Bugtraq mailing list archives
RE: Windows XP explorer.exe heap overflow.
From: "Larry Seltzer" <larry () larryseltzer com>
Date: Wed, 25 Feb 2004 10:48:31 -0500
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."
Current thread:
- Windows XP explorer.exe heap overflow. sunglasses (Feb 23)
- Re: Windows XP explorer.exe heap overflow. Eli K. (Feb 24)
- RE: Windows XP explorer.exe heap overflow. Larry Seltzer (Feb 25)
- Re: Windows XP explorer.exe heap overflow. Eli Kara (Feb 25)
- Re: Windows XP explorer.exe heap overflow. Dragos Ruiu (Feb 26)
- RE: Windows XP explorer.exe heap overflow. Larry Seltzer (Feb 25)
- Re: Windows XP explorer.exe heap overflow. Tim (Feb 24)
- <Possible follow-ups>
- Re: Windows XP explorer.exe heap overflow. Chris Calabrese (Feb 23)
- blocking gzip encoded files Darwin Mecham (Feb 23)
- Re: blocking gzip encoded files mgotts (Feb 24)
- Re: blocking gzip encoded files Josep L. Guallar-Esteve (Feb 24)
- blocking gzip encoded files Darwin Mecham (Feb 23)
- RE: Windows XP explorer.exe heap overflow. Michael Wojcik (Feb 23)
- Re: Windows XP explorer.exe heap overflow. Eli K. (Feb 24)