[12868] in bugtraq
Re: new IE5 remote exploit
daemon@ATHENA.MIT.EDU (krisp)
Tue Dec 7 11:51:49 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.BSF.3.96.991206181430.21105A-100000@protozoa.mach.net>
Date: Mon, 6 Dec 1999 18:19:02 +0000
Reply-To: krisp <krisp@PROTOZOA.MACH.NET>
From: krisp <krisp@PROTOZOA.MACH.NET>
X-To: Dustin Miller <dmiller@WFDEVELOPMENT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <GGEOLAAIGLMGDDIAGPIGMEMMCAAA.dmiller@wfdevelopment.com>
This exploit also seems ineffective against the version of IE that is
bundled with Windows 2000 Professional RC3 (build 2183). MSDXM.OCX:
Version: 6.4.9.1109
Size: 842,240 (on disk)
IE Version: 5.00.2920.0000
On Mon, 6 Dec 1999, Dustin Miller wrote:
> This exploit does not seem to affect the version of Internet Exploder
> bundled with Windows Millennium Beta 2 (build 4.90.2419). That version of
> IE is reported as 5.50.3825.1300, and the pertinent information for
> MSDXM.OCX is as follows:
>
> Version: 6.4.7.1028
> Size: 843,536 bytes
>
> MSDXM.OCX is a directshow filter, that parses directshow streams to an
> appropriate codec, receives the response, and uses the other DirectX
> functions to draw (or play) the resulting stream to the user's hardware (at
> least, that's what I've been able to glean from some documentation). And,
> no doubt, the newer version suffers from some similar stack overrun
> characteristics.
> _____
>
> Dustin Miller, President
> WebFusionDevelopmentIncorporated
>
>
> -----Original Message-----
> From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]On Behalf Of Jeremy
> Kothe
> Sent: Sunday, December 05, 1999 8:32 PM
> To: BUGTRAQ@SECURITYFOCUS.COM
> Subject: new IE5 remote exploit
>
>
> 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
>
