Hi All -
We've had an opportunity to investigate this issue, and want to advise that
a fix already is available. The vulnerability is fixed in IE 5.0b, which
ships as part of Windows 98 Second Edition. It also is eliminated by the
patch for the "Malformed Favorites Icon" vulnerability
(http://www.microsoft.com/security/bulletins/ms99-018.asp), which was
released in May. The reason that the security bulletin did not discuss
this fix is because we discovered the unchecked buffer during a routine code
review, and corrected it as a code quality issue.
The vulnerability is present in IE 4.0 as well, and we are developing a
patch that we'll release shortly. When the IE 4.0 patch is available, we'll
release a security bulletin that discusses the issue and where to get the
patch. Regards,
[EMAIL PROTECTED]
-Original Message-
From: Jeremy Kothe [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 15, 1999 3:02 PM
To: [EMAIL PROTECTED]
Subject: telnet.exe heap overflow - remotely exploitable
Heap Overflow in windows 98 Telnet.exe - remote via IE5
Jeremy Kothe ([EMAIL PROTECTED] or [EMAIL PROTECTED])
More fun and games courtesy of Microsoft (c:)...
Telnet.exe - (77824 bytes, 11th May 98)
---
This version of Telnet (which ships as part of Windows 98)
has a bug which allows a heap overrun. It assumes
that the first command-line argument will be <255 chars
when preparing for the "Connect Failed" message-box. The
result is that a few crucial bytes can be written over,
which, as the telnet app is closing, allow full execution
of arbitrary code. See below for full details...
This is still all local, though, so let's skip to the
REMOTE part.
IE 5.00.2314.1003/5.00.2314.1003IC
--
Internet Explorer automatically invokes telnet when given
an "rlogin:", "telnet:" or "tn3270:" protocol URL. Earlier
versions of IE which I experimented with had comparitively
tight restrictions on the format of the url, only allowing
two parameters through (two zeros to you and me ;) As it
turns out, this is not enough (for me) to exploit the bug.
But with the versions named above, which as of writing
include the latest version Microsoft would let me
download, the restrictions seem to have been lifted. I can
only assume that this is either unintentional, or that
tn3270 or telnet applications have been found which makes
this desirable... Whatever! The end result is that it
seems the most recent versions of IE 5 will faithfully
pass any collection of parameters up to about 460 chars
into telnet.exe.
Systems at risk
---
Windows 98 default installation with SOME versions of IE5.
If you click on a link, or are refreshed to a link, then
see telnet.exe pop-up, complaining that it can't connect
to a garbage-type address, DO NOT close the telnet
executable. Instead, either forcefully terminate the
process, or reboot. The exploit does NOT take effect until
telnet.exe is closing.
Solution
Either remove telnet.exe from the path, so IE cannot launch
it, or get a copy of the WinNT telnet.exe.
Exploit - introduction
--
Heap overruns are not for the faint of heart. If you have
trouble following stack overrun exploits, turn back now -
or go and learn, then come back.
With a stack overflow, getting the machine to execute into
our buffer is relatively easy. We have, after all,
overwritten the function return address. Point this
(indirectly or not) at the esp and you're in business.
Without this benefit, we have a much tougher time
exploiting the overrun. In fact it is entirely possible
that no exploit is possible.
It all depends on what follows our buffer in memory.
The best candidates for overwriting are pointers. If we can
overwrite one which the program subsequently uses, we have
a chance to make something happen.
The trick is to ignore what the program is trying to do,
and to look at what it's doing.
One core idea I've found to be of value is this: One way to
get execution onto the stack is to find a way to manipulate
our uncorrupted stack. Often you will find a pointer to the
stack (or command-line) somewhere not far from the top (of
the stack). If it can be moved only a few bytes, or we can
conspire to pop more than we push, we can then return to
our buffer.
Exploit - Intermediate - (Tools: SoftICE/IDA/PSEDIT)
The overrun we are presented with is only a handfull of
bytes, just enough to overwrite one pointer value following
the buffer in memory. This pointer, as it turns out,
originally points to an array of 1024 pointers, which are
either NULL, or point in turn to a 16-byte structure. From
context this seems to be a file-handle table of sorts.
When I examined the routine (fflush) where we end up
referencing the pointer, it turns out that the code
iterates thru the 1024 pointers, and for each non-NULL
entry, it e
