It doesn't refute my statement about the possibility that
a particular program running on two different OSs may
not be running the exact same code fragments though.
Yeah, I remember having to ask the OS environment back in the VB 5 16/32
bit development days, which OS environment was the application running on
a 16 bit Windows environment or 32 bit Windows environment because of the
fat client application being deployed to Windows 3'x, Win 9'x, ME and NT
workstations. If the app is running in the 16 bit Windows environment use
the 16 bit API calls and use the 16bit dlls. If the app is running in the
32 bit environment use the 32 bit API calls and use the 32 bit dlls.
That's about all that I know about what O/S the program is running on.
It's the program running that has the control and makes the decisions.
As an analogy look at the way an HTML web page that
desires to render equally well on Netscape as it does on
Internet Explorer accomplishes that feat. Somewhere in
the code there is a test for which environment it is currently
in, and the result of that test is the logic state for some other
conditional branches elsewhere in the code. The conceptual
architechture of this function is an interface between the two
different sets of supported HTML. The same page (program)
runs different code dependent on the environment.
And yes, I have done that too with Intranet applications using Netscape
and IE that was deployed in the company workstations.
The DCOM RPC vulnerability is in an (conceptually speaking)
interface, which is why I suggested that it *might* be possible
that WinME wouldn't be affected by this vulnerability in an
interface while another OS was affected.
IMHO here, DCOM is DCOM. And in today's environment using 32bit VB 6 or
VB.NET, along with using 32bit Micro Soft Transaction Server (MTS) or 32
bit COM+ technology, DCOM is used on the 32bit Win O/S workstation in n-
tier Object Programming Technology to find the tier or what machine the
dll for the application resides, when all that is installed on the
workstation is the exe and the runtime components for VB.
I'm not saying that this is or is not the case with this particular
vulnerability, only that it is conceiveably possible.
I just see this as the way things work with MS technology, because DCOM
and RPC are doing what they are meant to be doing in a closed
environment. And people have learned how to exploit this technology with
these workstations being in the home environment connected to the
Internet. I guess it is a vulnerability in that respect -- get the patch
and get a FW -- big deal!
The DCOM RPC vulnerability is in an (conceptually speaking)
interface, which is why I suggested that it *might* be possible
that WinME wouldn't be affected by this vulnerability in an
interface while another OS was affected.
I really don't know how a machine would be attacked using DCOM on the
machine other than an exe or a dll compromised the machine and it used
DCOM and RPC to make contact with the server dll over the Internet.
The other thing was that I had seen a (basic) conceptual block
diagram of the DCOM RPC system where it showed the stubs,
the interfaces, the network, and the client and server machines.
The "system" had to interface with the network so that it could
abstract the particularities and operate without a care as to what
network protocols were being used between points. Also it had
to interface with the server and client OSs.
If I run across that diagram again I will show you what I was
talking about. Maybe then you will be better equipped to
point out my (probable) misconceptions.
The bottom line as to what this is all about is the application being
able to participate in a MTS or COM+ transaction. The database dll for a
Purchase Order application is installed on the MTS or COM+ server. Code
in placed into the db.dll for MTS or COM+ transaction processing.
The Purchase Order application updates the Inventory database record,
makes a Shipping database record and a Accounts Receivable database
record. During each process of the transaction, a vote is taken with MTS
or COM+. At any point during the transaction a part of the transaction
fails, MTS or COM+ tells the databases anything thing you have done
prior to the transaction failure, roll it back to it's previous state,
otherwise, if everything is successful commit the transactions to the
databases.
MTS and COM+ controls the traffic to and from the database for the
application. BEGIN, ABORT, COMMIT TRANSACTION.
People have found a way to expolite this for other means.
You should see this work on a Windows Terminal Server farm with EXE,
BUS.dll, and DB.dll being installed on the servers and the DB.dll being
installed on the COM+ server, with users coming via the Internet using
IE.
Duane
