Bugtraq mailing list archives
new IE5 remote exploit
From: paceflow () HOTMAIL COM (Jeremy Kothe)
Date: Sun, 5 Dec 1999 18:32:02 PST
IE5 remote exploit # 2 - Jeremy Kothe (paceflow () hotmail com) Overrun: vnd.ms.radio:\\ ------------------------ Evaluating "vnd.ms.radio:\\aaaaaaaaaaa...." causes an exploitable stack overrun. ie: By providing an oversize (360 byte) URL using the vnd.ms.radio protocol, a malicious web site or e-mailer (or...) can cause arbitrary code to be executed on a client machine. Systems Affected ---------------- The file with the overrun is MSDXM.OCX - 807,184 bytes. It came to me with IE 5.xxx, and is identical on every installation I've so far seen. Both NT and Windows 9x are vulnerable. Tested with: IE: 5.00.2314.1003IC IE: 5.00.2614.3500 Windows: 98 OSR 1 NTW 4.0 SP5 Not tested with: Windows 2000 IE: Latest Patches Also, I did find one W98 machine which was immune - I didn't have time to figure why... Details ------- The following is the binary for a URL or link which overflows the stack and displays a simple MessageBox, then loops endlessly (ExitProcess wasn't around). I've used addresses from MSDXM.OCX, which is where the overrun is. If you banged your head against richedxx.dll (solar d. spyrit,...), then you'll appreciate this file. It's mapped at 0x1d300000 and is 800k. With all chars except 0, 9, 0a, 0c, 20, 22, 23, 25, 2e, 2f, 5c allowed in the buffer. Off Text Binary (where non-text) ------------------------------------------------ 000 vnd.ms.radio:\\j 010 kwashere9991.... C0890783 020 ..PWWP....0...00 EF0C, FF151416, 1DEBFE 030 0000000000000000 040 0000000000000000 050 0000000000000000 060 0000000000000000 070 0000000000000000 080 0000000000000000 090 0000000000000000 0A0 0000000000000000 0B0 0000000000000000 0C0 0000000000000000 0D0 0000000000000000 0E0 0000000000000000 0F0 0000000000000000 100 0000000000000000 110 0000000000000000 120 0000000000000000 130 0000000000.00000 1D 140 00.000.000.000.0 1D, 1D, 1D, 1D 150 000.o6.0000000.0 1A6F361D, 1D 160 000000.0 1D ------------------------------------------------ Straight after the "vnd.ms.radio:\\", there is data, then code. I put them there because there's over 0x100 bytes of space here, and edi points to offset 1bh at the point of no return. If you need more space (writing a word processor?), IE allows somewhere between 2-4k in addition to what I've used. (which would be large enough for a modest "worm".) The address at offset 154h overwrites the return address with a pointer to a "call edi"... which calls the code... All the other "1D"'s are to provide readable pointers to avoid exceptions while waiting for the end of the call. (They're actually 0x1d303030's.) How did it happen? ------------------ I coded the exploit without paying much attention to what the source was saying, then at the end decided I'd go and find out how a relatively new piece of software like this could allow a dreary old unchecked stack overflow. The original exception was reported within msvcrt.dll's mcsstr function. The stack had been overwritten, but the arguments and return address for mcsstr (and no further) were written over the top. This meant the overrun must have ocurred in the calling function. (Besides, I trust Microsoft to know their crt by now.) The return address is in MSDXM.OCX at 0x1d365585. Looking back upwards from the call to mcsstr, the previous call is to _mbsnbcat (strncat). Should be safe enough. Above that is _mbsrchr (strrchr). That's begnign also. Next comes the (I suppose) inevitable - an inline strcpy into a 0x100 byte buffer situated on the stack 0x40 bytes into the local frame. Examining further reveals that the author is assuming that the final portion of the url (after the last forward or back-slash) is less than 256 chars. Basically, it boils down to: { char acBuffer[ 256 ]; strcpy( acBuffer, pszInput ) } again. Conclusions ----------- 1. Static buffers kill. 2. Functions which fill buffers without size constraints are evil. 3. If you don't know how big it is, find out before you copy it. 4. None of these conclusions are new. In short, sized strings: 12329852, null-terminated strings: 0. The root of the problem is this: The API's of nearly all OSes require terminated strings. The programmer is therefore required to use them, and because the provided functions for converting are so messy, and the support functions for sized strings so (comparitively) convoluted that using sized strings internally while converting them for the API is not practical. Programming for Windows in particular gets messy, because you must use ANSI-style strings to maintain 9x compatibility, and convert to sized to use COM/OLE. If you EVER see a classic-style overrun in, say, a Delphi app, you know it was related (however distantly) to an API call. Other than that, there is no reason to use anything but "string"s, and therefore no maximum string lengths - Unless you count 4gb as a limit... (one day.) The C-Standards people need to do something. This is an almost uniquely C-based problem. Deprecate null-terminated strings and/or any function which fills one without a maximum. Make sized strings a compiler-supplied service with syntax as simple as vb or delphi, with typecasting support for converting for API's. Relying on classes and macros is very noble, but produces unavoidable syntactical subtleties which detract from the simplicity of the concept of string-manipulation. This leaves most programmers resorting to the (still too-messy) concept of using BSS or stack buffers. Why should any programmer have to think about people feeding programs into their "strings"? Strings should be as easy to use as integers. Arrays of characters can then revert to being... just that, and can be strictly bounds-checked... and the script kiddies will have to learn cryptography... and might get jobs. ------------------------------------------------ This bug was brought to you by Bell, AT&T, Microsoft and the letter 0x61. - Jeremy Kothe (paceflow () hotmail com) ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Current thread:
- new IE5 remote exploit Jeremy Kothe (Dec 05)
- Re: new IE5 remote exploit Dustin Miller (Dec 06)
- Re: new IE5 remote exploit krisp (Dec 06)
- Analysis of trin00 Dave Dittrich (Dec 07)
- Re: Analysis of trin00 Stefan Aeschbacher (Dec 09)
- Re: Analysis of trin00 Jacob Langseth (Dec 09)
- ISSalert: ISS Security Advisory: Buffer Overflow in Solaris Snoop Aleph One (Dec 09)
- Re: Analysis of trin00 Stefan Aeschbacher (Dec 09)
- xsw 1.24 remote buffer overflow Aleph One (Dec 09)
- Re: new IE5 remote exploit Dustin Miller (Dec 06)
- Analysis of Tribe Flood Network Dave Dittrich (Dec 07)
- Re: Analysis of Tribe Flood Network Mixter (Dec 08)