DCOM worm on the rampage

  • Thread starter Thread starter Gabriele Neukam
  • Start date Start date
I just received warning in a German security newsgroup that a new worm
makes use of the RPC DCOM vulnerability (whatever this is; my olde WinME
computer probably doesn't have this.

Link given is <http://isc.sans.org/diary.html?date=2003-08-11>

Keep your shares tight.


Gabriele Neukam

(e-mail address removed)
Click to expand...

http://www.usrbingeek.com/a/000482.php

You will notice the words in the link *All Windows O/S's* Win ME is just
a bad version of Win 98. And ME has DCOM on it like the Sun comes up in
the morning. :)


Duane :)
 
totojepast said:
What about different propagation vectors? For instance, if somebody
would run MSBlast.exe delivered via e-mail, would MSBlast.exe work the
same way?
Click to expand...

I don't see why not depending, on the platform. If MSBlast
is executed, it is an instance of the worm. The exploit is for
an automated download and execution vector only. It doesn't
mention a "programmed in" e-mail vector, but that doesn't
mean it can't be e-mailed/spammed (SE, trojan.downloader,
other exploits) by direct human action or web based exploit.
 
Duane Arnold said:
http://www.usrbingeek.com/a/000482.php

You will notice the words in the link *All Windows O/S's* Win ME is just
a bad version of Win 98. And ME has DCOM on it like the Sun comes up in
the morning. :)
Click to expand...

There are many places on the internet that disagree with that assessment.

http://resnet.albany.edu/news/RPCvuln.html
http://www.jmu.edu/computing/security/info/dcombug.shtml

Even the Microsoft knowledge base states that WinME is not
affected. I don't suppose that means that you can't install this
vulnerability on WinME if you desired (A link you posted in
a previous thread indicated how to do so on Win9x and ME).

Microsoft should know what (default) platforms are affected,
after all ~ they wrote the vulnerability in the first place. ;o)

....but what Microsoft *should* know and what they *do*
know are often very different things.
 
David H. Lipman said:
Wrong again !

WinME is the *best*, and the last, of the Win9x family and is NOT affected by the
vulnerability.

DCOM has been around since Win95. The vulnerability *only* affects NT based OS's
(WinNT4, Win2K, WinXP, WinXP/64, Win2003 and Win2003/64).
Click to expand...

So, you can install RPC DCOM on the Win9x machines, but it is
a different animal than that used with the NT kernels?
 
There are many places on the internet that disagree with that
assessment.

http://resnet.albany.edu/news/RPCvuln.html
http://www.jmu.edu/computing/security/info/dcombug.shtml

Even the Microsoft knowledge base states that WinME is not
affected. I don't suppose that means that you can't install this
vulnerability on WinME if you desired (A link you posted in
a previous thread indicated how to do so on Win9x and ME).

Microsoft should know what (default) platforms are affected,
after all ~ they wrote the vulnerability in the first place. ;o)

...but what Microsoft *should* know and what they *do*
know are often very different things.
Click to expand...

I have used DCOM on the Win 9'x, ME and NT O/S's. Accoriding to another
post, home user's may have it installed, including ME. I don't know why
but I guess it is possible.

And like we talked once before on a Win 9'x and the ME root based O/S's,
if it can be executed on the machine -- like a worm via email it can be
hooked-up.


Later!

Duane :)
 
So, you can install RPC DCOM on the Win9x machines, but it is
a different animal than that used with the NT kernels?
Click to expand...

http://www.microsoft.com/com/tech/dcom.asp

It allows a client machine to make calls to dll's setting on a
centralized server machine (it doesn't have to be a O/S server) -- a
workstation too. The dll's which are a library of program routines can be
business objects, database objects, etc. The client machines make calls
to the dll's through an exe that is on the client machine to do
processing. The point of failure is at one point instead of the dll's
being deployed to all machines (a fat client machine) as apposed to a
(thin client machine exe only). DOCOM allows the client machines to
connect to the server machine via TCP/IP to the server machine and share
the dll's.

Win 95 to NT machines can be setup to do this. Win 2k workstation can be
set with DCOM to go find a NT machine that is the server of the dll(s)
too. M$'s move towards centralized processing.

Now the move is towards Win 2K or XP Pro workstations COM+ and a COM+ O/S
Win2k server, Win 2k ADV or 2K3 server. It's the same thing just a
different tune.

Duane :)
 
Duane Arnold said:
http://www.microsoft.com/com/tech/dcom.asp

It allows a client machine to make calls to dll's setting on a
centralized server machine (it doesn't have to be a O/S server) -- a
workstation too. The dll's which are a library of program routines can be
business objects, database objects, etc. The client machines make calls
to the dll's through an exe that is on the client machine to do
processing. The point of failure is at one point instead of the dll's
being deployed to all machines (a fat client machine) as apposed to a
(thin client machine exe only). DOCOM allows the client machines to
connect to the server machine via TCP/IP to the server machine and share
the dll's.

Win 95 to NT machines can be setup to do this. Win 2k workstation can be
set with DCOM to go find a NT machine that is the server of the dll(s)
too. M$'s move towards centralized processing.

Now the move is towards Win 2K or XP Pro workstations COM+ and a COM+ O/S
Win2k server, Win 2k ADV or 2K3 server. It's the same thing just a
different tune.

Duane :)
Click to expand...

Hi,

Is this the correct Microsoft patch for Windows XP Home Edition?

http://microsoft.com/downloads/deta...6C-C5B6-44AC-9532-3DE40F69C074&displaylang=en

Thanks,

Alpha
 
Duane Arnold said:
http://www.microsoft.com/com/tech/dcom.asp

It allows a client machine to make calls to dll's setting on a
centralized server machine (it doesn't have to be a O/S server) -- a
workstation too.
Click to expand...

I read that as "distributed" not "centralized". The machine making
the call (requesting service) is the client, and the machine executing
the code and returning any result is the server. The DCOM system
must interface the server-side both to the platform and to the network
as must the client-side. This would mean that the interfaces themselves
would differ with respect to the OS platform they are installed on.
Maybe this is why the vulnerability doesn't apply to ME, because the
vulnerability is in the OS to DCOM RPC interface itself.
 
FromTheRafters said:
I read that as "distributed" not "centralized". The machine making
the call (requesting service) is the client, and the machine executing
the code and returning any result is the server. The DCOM system
must interface the server-side both to the platform and to the network
as must the client-side. This would mean that the interfaces themselves
would differ with respect to the OS platform they are installed on.
Maybe this is why the vulnerability doesn't apply to ME, because the
vulnerability is in the OS to DCOM RPC interface itself.
Click to expand...

Interestingly, the Sophos site says:

Windows 95/98/Me computers, which don't run an RPC
service or have a TFTP client (default setting), are not at risk.

Of course they are referring to the worm here and not the
vulnerability itself. However, it seems to imply the converse
~ that if they *do* run an RPC service, that they *are*
vulnerable to at least the buffer overrun exploit part of the
worm.

....so, I'm back to believing that the vulnerability is indeed
installable on Win9x/ME systems. Unless of course that
Sophos blurb gave too much extra information and they
really meant to say ~

Windows 95/98/Me computers [removed extra information]
are not at risk.

The more I read, the less I know....
 
I read that as "distributed" not "centralized". The machine making
the call (requesting service) is the client, and the machine executing
the code and returning any result is the server. The DCOM system
must interface the server-side both to the platform and to the network
as must the client-side. This would mean that the interfaces
themselves would differ with respect to the OS platform they are
installed on. Maybe this is why the vulnerability doesn't apply to ME,
because the vulnerability is in the OS to DCOM RPC interface itself.
Click to expand...

I am sorry Raft, I am not trying to be smart with you. But you do not
know what you are talking about here. I the VB or C++ programmer writes
code in the VB or C++ IDE environment. This code I create can be a series
of Functions or Subroutines that accept parameters passed to these
routines and the routines execute their code based on the parms passed.
The program is compiled into a DLL.And during this development process,
the EXE or other dll's that must interface with the objects of this dll
are early or late bounded to the dll. Bounded being the known interface
or contract being made by the program that wants to use the objects of
the dll. It is called Object Oriented Programming. The reuse of program
objects by the client side part of the application by many client
machines.

The parms being passed by the client side application must know about the
interface of the server side program's or (dll) interface or contract
between the two entities. And the contract cannot be broken by the two,
where as, the parm interface on the dll side for a routine has been
changed but the client side program didn't know about the change.

MS VB and C++ applications run on any Windows O/S platform workstation or
server. And it doesn't make any difference on what O/S it is being used,
because the interface or contract is between the client and server
programs and is platform independent.


Duane :)
.. .
 
On that special day, Duane Arnold, ([email protected]) said...
I have used DCOM on the Win 9'x, ME and NT O/S's. Accoriding to another
post, home user's may have it installed, including ME. I don't know why
but I guess it is possible.

And like we talked once before on a Win 9'x and the ME root based O/S's,
if it can be executed on the machine -- like a worm via email it can be
hooked-up.
Click to expand...

Agreed, but for that DCOM has to be installed first, by installing
application related to this service. AFAIK (wish I knew where I read
it), it isn't installed by default on home user machines, but rather on
the Windows Server machines.

And I had believed that the SOHO NT computers also seemed to be shipped
w/o DCOM as a default installation. Reading the cries for help in here,
I get the feeling that I was wrong. Maybe I should get the fix for my
sister's computer; she hasw an XP, too.

Argh. I *bet* I read this just two days before the MSBlast hit, on some
MS knowledge base page. Maybe it is the one referred to by David H.
Lipman.


Gabriele Neukam

(e-mail address removed)
 
Bart Bailey said:
In Message-ID:<[email protected]> posted on Tue, 12 Aug


Maybe it's not how much you read,
but how much you read into what you read <g>
Click to expand...

That's most likely it, which is why I prefer more concise
language, and I so often ask for definitions of terms. :o)
 
Duane Arnold said:
I am sorry Raft, I am not trying to be smart with you.
Click to expand...

That doesn't matter, I'm pretty thick skinned (and thick headed too). ;o)
....but thanks for being clear on that.
But you do not know what you are talking about here.
Click to expand...

I'm just wondering why the Microsoft write-up on the vulnerability
says "Systems not affected ~ ME" ...of course Win95/98 isn't even
mentioned as if they are a painfully bad memory. ;o) They didn't
say WinME(default) or WinME (without DCOM) or some such.
I the VB or C++ programmer writes
code in the VB or C++ IDE environment. This code I create can be a series
of Functions or Subroutines that accept parameters passed to these
routines and the routines execute their code based on the parms passed.
The program is compiled into a DLL.And during this development process,
the EXE or other dll's that must interface with the objects of this dll
are early or late bounded to the dll. Bounded being the known interface
or contract being made by the program that wants to use the objects of
the dll. It is called Object Oriented Programming. The reuse of program
objects by the client side part of the application by many client
machines.
Click to expand...

Okay... said:
The parms being passed by the client side application must know about the
interface of the server side program's or (dll) interface or contract
between the two entities. And the contract cannot be broken by the two,
where as, the parm interface on the dll side for a routine has been
changed but the client side program didn't know about the change.

MS VB and C++ applications run on any Windows O/S platform workstation or
server. And it doesn't make any difference on what O/S it is being used,
because the interface or contract is between the client and server
programs and is platform independent.
Click to expand...

Yes, but just because an application written in a HLL or 4GL
runs on different platforms as if they were equivalent, doesn't
mean it uses the exact same code fragments to do so. Isn't it
conceiveable that a vulnerability could exist in an interface and
not be applicable to *all* installations?
 
Yes, but just because an application written in a HLL or 4GL
runs on different platforms as if they were equivalent, doesn't
mean it uses the exact same code fragments to do so. Isn't it
conceiveable that a vulnerability could exist in an interface
and not be applicable to *all* installations?
Click to expand...

Guys,

If I understand the underlying point it is that if a piece of code
runs on more than one platform and breaks under particular circs on
one of them, you would expect that it should also begave the same
on the other platforms.

However, this particular vulnerability depends on generating a
buffer overflow and exploiting the consequences. It may provoke an
exception condition that is handled very differently by NT-derived
versus Win9x/ME OSes.

To illustrate the point: Imagine porting software from a platform
on which works 'perfectly' to a new platform. A particular test
crashes the second platform, but not the first. On investigation, a
fault is found in the source code that accounts for the problem.
The fault was always there on the first platform it just didn't hit
anything sensitive, so nobody noticed. Been there, done that, etc
:-)

JB
 
Back
Top