COMMAND

    DCOM

SYSTEMS AFFECTED

    WinNT

PROBLEM

    Rob Lempke found following.  Using  the code below he was able  to
    create 20  instances of  Excel on  my co-workers  machines without
    modifying their machines  at all.   The target must  be Windows NT
    Workstation/Server running sp3  or sp4. sp5  seems to prevent  the
    attack.

    Private Sub Command1_Click()
        Dim xlObj As Object
        Dim xlCollection As New Collection
        Dim i As Long
        For i = 1 To 20
            Set xlObj = CreateObject("Excel.Application", "\\NTBox")
            xlCollection.Add xlObj
        Next i

        i = 1
        'clean up
        While xlCollection.Count > 0
            xlCollection.Remove (xlCollection.Count)
        Wend
        Set xlCollection = Nothing
    End Sub

    Depending  on  the  access/launch/configure  ACLs  on a given DCOM
    object, authentication may or  may not matter. Using  the DCOMCNFG
    utility  (included  with  NT4/5  and  Win95/98),  you can view the
    Access/Launch/Configure permissions for  the DCOM objects  present
    on your system (that are  accessible via the network).   Depending
    on  how  farmiliar  the  person  who  wrote  the  DCOM app is with
    CoInitializeSecurity  (the  COM  API  call  for  setting  ACLs for
    Access/Launch/Configure),  there  are  programmatic  methods   for
    launching,  configuring,  or  deleting  COM  objects  on  a remote
    machine (as shown  in the VB6  program below). This  is similar to
    the problem of many win32  coders not setting ACLs on  named pipes
    and other objects their applicatitons create.

    The target (DCOM or server) which must be running the DCOM  object
    (exe, not dll's  or ocx's), must  be Windows NT,  sp3 or sp4  with
    the  rpc  service  running  and  the  no TCP filters running.  The
    client  can  be  any  win32  platform  with DCOM installed.  (DCOM
    comes with  NT/98 but  not 95).   The bug  is that  before service
    pack 5 (at least here)  the Everyone group has DEFAULT  ACCESS and
    LAUNCH permissions.

    Some additional  info.   The target  and tester  were on  the same
    domain, both  as Users  (with default  user permissions,  i.e. not
    ADMIN).   Tester  was  an  Everyone/Authenticated  user  from  the
    targets point of view.  Tester could see his/her shares.

    Default DCOM permissions set to on the target:

        Access:
                Interactive-Allow Access
                (This Machine)\Administrator-Allow Access
                System-Allow Access
                Everyone-Allow Access
        Launch:
                Interactive-Allow Launch
                (This Machine)\Administrator- Allow Launch
                System-Allow Launch
                Everyone- Allow Launch
        Configuration:
                Interactive
                (This Machine)\Administrator-full
                System-full
                Creator Owner -special
                Everyone-read

SOLUTION

    Rob  researched  this  issue  with  Microsoft and figured out what
    was wrong.   It turned out  to be an  environmental issue as  many
    people suspected.  The problem:  many machines in the domain  have
    the Domain  Users group  as a  member of  the Local  Administrator
    group.  (Doh!) This was the reason he was able to create instances
    of excel on other  machines that it seemed  he shouldn't.  I  will
    leave this  advisory here  as many  people were  able to reproduce
    this which means they have same enviroment issue.  Not a bug,  but
    a security consern if done wrong.