[12188] in bugtraq
Re: ActiveX Buffer Overruns
daemon@ATHENA.MIT.EDU (Todd Sabin)
Fri Oct 8 20:23:03 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <m3puysw3pf.fsf@buckaroo.qnz.org>
Date: Wed, 6 Oct 1999 17:59:24 -0400
Reply-To: Todd Sabin <tsabin@BOS.BINDVIEW.COM>
From: Todd Sabin <tsabin@BOS.BINDVIEW.COM>
X-To: Chris <mlnn4@oaks.com.au>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Chris's message of "Wed, 6 Oct 1999 21:18:05 +1000"
Chris <mlnn4@oaks.com.au> writes:
> On Mon, 4 Oct 1999 07:52:53 +0200, Aviram Jenik wrote:
> >Buffers passed to a COM object (or ActiveX control: it's the same thing) are
> >marshaled by the COM subsystem [snip]
>
> Scuse me for butting in, but I have to say that this is only partially
> correct.
>
> YES, the com subsystem will marshall data sent to/from a 'remote' COM object
> (be that a separate process on the same system, or a process on a remote
> machine).
>
> But NO, the com subsystem does NOT marshall data for an inproc server (i.e.
> any COM object exposed as a .DLL, .OCX, or .whatever-Microsoft-calls-them-
> today.
>
> If the object is loaded into the calling processes address space, then the
> method and property accesses are not marshalled.
>
This is also only partially correct. The thing which determines
whether a COM call gets marshalled is whether the called object lives
in the same apartment as the calling thread; furthermore, process !=
apartment.
Briefly (as if anything COM related could be described briefly), every
thread in a process that wants to use COM has to declare via
CoInitializeEx what apartment it will be in: either its own single
threaded apartment (STA) or the multi-threaded apartment (MTA). A
given process may have multiple STAs, but only one MTA.
Ok, now when a thread wants to create some object so it can call
methods on it, it gets access to it via CoCreateInstance (a
simplification). Now, this may or may not create that object in the
same apartment as the thread which is creating it. That's determined
by whether the object's threading model (which is stored in the
registry) is compatible with the calling thread's declared apartment
type. If they're not compatible, then the object will be created in
another apartment (possibly creating a thread for said apartment), and
the original thread will be handed a proxy to marshal calls over to
the created object's apartment. Whee...
If you're not confused yet, there are actually more possibilites.
Consult the back issues of MSJ, or MSDN. And, of course NT5 is going
to make things even more fun with COM+.
> As the majority of COM object accesses of the type we are talking about in
> -this- thread (that being, I understand, activeX or other com objects
> embedded in a browser's rendition of a web page) are in fact inproc, then
> marshalling is not a factor that can be relied upon.
>
It seems the only way to know is to examine every COM object used by
IE, and see if they are all compatible with the threads they're
created from. Good luck. :)
Todd
