IE 4.01 bugs in Win95 & WinNT. (long)

Aleph One (aleph1@DFW.NET)
Mon, 16 Mar 1998 10:35:00 -0600

---------- Forwarded message ----------
Date: Mon, 16 Mar 1998 10:15:29 -0500
From: "Abe L. Getchell" <agetchel@KDE.STATE.KY.US>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: IE 4.01 bugs in Win95 & WinNT. (long)

Hello all,
I found three bugs in Internet Explorer 4.01 running under both Windows
95 and Windows NT 4.0 (Server and Workstation w/ SP3). The bugs are
caused by malicious code which makes IE crash in all three situations. I
have NOT, however, found other ways for these bugs to be exploited to let
people cause more serious damage to the system. I am still experimenting
with variations of the orignal bug and will relay any important
information on to you all, if and when it arises. The following details
each bug...

Bug #1:
This is the origional bug I found. When loaded in IE 4.01 on both
Windows 95 and Windows NT 4.0 systems, it will crash the browser. In
Windows 95 this bug causes two successive illegal operations, and causes
Active Destop to "lose it's settings" if being used. In Windows NT 4.0
it gives you a Dr. Watson which tells you that IEXPLORE.EXE caused a
stack overflow, and causes Active Desktop to "lose it's settings" if
being used. What I am doing here, is using the "data" attribute of the
"object" tag to reference itself. This misuse of the object tag causes
the broswer to go into a loop, and eventually to meet it's maker with the
following errors:

Windows 95 errors:
-EXPLORER causes a stack fault in module SHDOCVW.DLL at 016f:7078d692.
-EXPLORER causes a page fault in module SHDOCVW.DLL at 016f:7078d692.
-Active Desktop "loses it's settings" if it's enabled.

Windows NT 4.0 errors:
-Dr. Watson gives: IEXPLORE.EXE > Exception: stack overflow
(0xc00000fd), Address: 0x7079024b.
-Active Desktop "loses it's settings" if it's enabled.

Here is the code which makes this happen. Make sure you save this code
in a file under the same name which is referenced in the object tag (in
this case, it's "crashmehtml.html"). Also, remember to remove the
comment tags before trying to load the file... if you don't nothing will
happen.

<!--
-->

Bug #2:
This is a variation of the origional bug I found. The ONLY difference
between this and bug #1 is the "script" tags in the head of the document.
When this is loaded in IE 4.01, on both Windows 95 and Windows NT 4.0
workstations, it will crash the browser. In Windows 95 it causes a stack
fault, then tells the user to close all programs and reboot the machine.=20
In Windows NT 4.0, Dr. Watson pops up and tells you IEXPLORE.EXE caused a
stack overflow. Why this makes IE crash in a different DLL, I don't
know. Anybody have any input on this one?

Windows 95 errors:
-EXPLORER causes a stack fault in module MSHTML.DLL at 016f:704bc4cc.
-Gives the error message: "There was an internal error and one of the
windows you were using will be closed. It is recommended that you save
your work and close all programs, then restart your computer.".

Windows NT 4.0 errors:
-Dr. Watson gives: IEXPLORE.EXE > Exception: stack overflow
(0xc00000fd), Address: 0x704bbbbc.

Here is the code. Again, make sure you save the code in a file which is
the same name as referenced in the object tag (in this case, it's
"crashmescript.html"). Also, remove the comment tags before testing out
the code... if you don't nothing will happen.

<!--
-->

NOTE: In the "script" tags, you can put anything you want. I tried
'language=3D"vbscript"', 'language=3D"javascript"', and
'language=3D"poopooplatter"' and the same error occured every time.

Bug #3:
What I have here is an html file (crashmeloop1.html) with a data
reference to itself AND a data reference to another file
(crashmeloop2.html), as well as another html file which references
itself, as well as referencing the origional file (crashmeloop1.html).=20
In Windows 95, this causes IE to go into a continuous loop while the HDD
grids away rather heavily. I have let this run up to 10 minutes and did
not receive an error message of any sort (stack overflow or virtual
memory). However, you cannot do anything until you ctrl+alt+del IE.=20
This is where the fun starts. After you "End Task" IE, the HDD grinds
away for a long amount of time, which I found is directly proportional to
the amount of time you let the loop run... i.e. if you let the loop run
for ten minutes, the HDD is goind to spin for a lot longer after the "End
Task" then if you let the loop run for five minutes. After the HDD stops
ginding, IE closes (although I noticed sometimes I have to move my mouse
to get it to close, tapping a key WILL NOT WORK), and you are returned to
the desktop. If Active Desktop is being used, it will have "lost it's
settings". In Windows NT, it is a different case. The program will loop
until an error message pops up saying "Your system is running low on
virtual memory. Please close some aplications. You can then start the
System option in the Control Panel and choose the Virtual Memory button
to create an additional paging file or to increase the size of your
current pagin file." IE then closes and nothing else happens (I verified
in Task Manager that IE is no longer running). I find it strange that
the Windows 95 machine didn't give me the same message since the heavy
HDD activity was obviously the system paging. I wonder how long I would
have to let a Windows 95 box run until it barfs? I have a feeling, that
you could remove the self reference in both files and it would do the
same thing on both systems. I have, however, not had a chance to do this
yet. Unfortunately, finding bugs in IE is not in my job description. :-)
I will test it out as soon as I get a chance.

Here is the code. The same applies to this code, as the other two
above.

<!--
-->

<!--
-->

Microsoft's position in this matter is, "The IE team has put this bug in
the bug database, and it will be fixed in the next release or service
release." Personally, I think that bugs like these in commercial
software are unacceptable, but I can understand why they took the
position they did. As Russ said in an e-mail to me, "...and while GP'ing
your machine is not a good thing, you're not likely to return to the site
that caused it...". Make of it what you will... If you have any
questions, feel free to contact me at agetchel@kde.state.ky.us. Thanks
for listening...

Abe
<BR>
<div>--------------------</div>
<div>Abe L. Getchell</div>
<div>System Support Services</div>
<div>Kentucky Department of Education</div>
<div>E-Mail: agetchel@kde.state.ky.us</div>
<div>Voice:&nbsp; 502.564.2020ext225</div>
<div>Fax:&nbsp;&nbsp;&nbsp;&nbsp; 502.564.4695</div>
<div>--------------------</div>