Internet Explorer 4.0

Internet Explorer 4.0 Buffer Overflow

Reported November 10, 1997 by The L0pht

Systems Affected

Internet Explorer 4.0

Document: L0pht Security Advisory
URL Origin:
Release Date: November 1st, 1997
Application: Microsoft Internet Explorer 4.0 Suite
Severity: Viewing remote HTML content can execute arbitrary native code
Author: [email protected]
Operating Sys: Windows 95

1. Copy the supplied HTML file(s) into a location that is accessible via the target application.
2. Point to it. Look at it.
3. Click on the link. (or let someone click it for you)
4. Become aware of what happens to your machine.

The Problem

The Microsoft Internet Explorer 4.0 Suite, including all programs supplied with it that read and/or process HTML from either local machines, intranet machines, or remote internet machines are subject to a buffer overflow in the HTML decoding process. The buffer overflow can cause the application to page fault, or in the worst case, execute arbitrary precompiled native code.

Technical Details

The problem here lies in the deciphering of the URL line format itself. The base HTML library that is used by the Internet Explorer 4.0 Suite and the following programs are vulnerable:

- Outlook Express (both mail and news)
- Windows Explorer
- Internet Explorer

This problem, because it stems from a programming flaw in the HTML decoding system, is unaffected by the Explorer "Security Zones" feature. In other words, if you turn on the highest security level for the zone from where the exploit HTML is being viewed, you are still vulnerable. The critical problem here is a buffer overflow in the parsing of a particular new type of URL protocol. The "res://" type of URL is meant to allow access to a local resource embedded in a local DLL file. This is useful for archiving entire websites into a DLL and is not, in its truest concept, a security flaw.

For example, to read something out of the IE4.0 Tour (stored in a DLL) try the following URL:


The buffer overflow is on the actual filename specified. To crash your machine go ahead and try res://blahblahblah ... blahblah/ in your Internet Explorer window where the amount of "blah" equals 265 characters.

The function that goes through the filename and validates it is flawed on Windows 95. Without checking the length, the filename is uppercased, concatenated with ".DLL" if it isn"t there already, and in the process, copied into a fixed size buffer.

Testing the Exploit:

When constructing the exploit we want to try something useful. Lets"s start with appending text of your choice to AUTOEXEC.BAT... (note that running native code lets you do pretty much anything you want)

Note that the location of the exploit string in the stack is very important and it varies from target application to target application.

Constructing the exploit string:

Figure out stack location for exploit code...

App Loc:

Internet Explorer 0x0057C144
Windows Explorer 0x0088A0F4

Yeah, I know that those locations have null bytes in them and you can"t put those (or lowercase letters, or CR/LF or 0x07 or anything like that) in the exploit string... but we"ll let microsoft fix that for us. Step thru the process to see IE add that extra null character for you. Will they ever cease to amaze...

Put together what you wanna do, tack on the necessary jump addresses and all that. That"s it.

Stopping the Problem:

Load Internet Explorer 4.01 located here

To learn more about new NT security concerns, subscribe to NTSD.

Reported by The L0pht
Posted here at NTSecurity.Net February 15, 1997
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.