COMMAND

    Visual Studio

SYSTEMS AFFECTED

    Visual Studio 6.0 Enterprise Edition

PROBLEM

    Following  is  based  on  a  Microsoft Security Bulletin MS01-018.
    The  VB-TSQL  debugger  object  that  ships with Visual Studio 6.0
    Enterprise  Edition  has  an  unchecked  buffer  in  the code that
    processes parameters for one of the object's methods.  The  object
    can, by  design, be  programmatically accessed  remotely.   If the
    object  were  to  be  referenced  by  a  program  that   contained
    specially  malformed  data  within  the  parameter,  either of two
    outcomes would  result.   In the  less serious  case, the attacker
    could cause the  object to fail  on the hosting  machine.  In  the
    more serious case, the  attacker could exploit the  buffer overrun
    to run code of the attacker's choice on the hosting machine.

    The debugger  object (vbsdicli.exe)  is installed  by default with
    Visual Studio 6.0  Enterprise Edition and  runs in the  context of
    the  interactively  logged-on  user.   The  attacker  could   only
    execute  a  successful  attack  if  he  knew  that  a user had the
    component installed and that the   user was logged in at the  time
    of the attack.

    If best  practices have  been followed  and ports  137-139 and 445
    have been blocked  at an organization's  router or firewall,  this
    attack could not be executed from the Internet.

    There  is  no  way  to  determine  remotely  if  a machine has the
    affected  component  installed.    An  attacker   would  need   to
    successively  target  machines  until   he  found  one  that   was
    susceptible.

    The vulnerability could only  be exploited if an  interactive user
    were logged on to the target machine at the time of the  malicious
    user's attack.

    Originally  this  has  been   found  by  BindView's  Razor   Team.
    Following is their input.   Microsoft Developer Studio installs  a
    variety of DCOM  components.  One  in particular is  the "VB T-SQL
    Debugger Object".  It is  installed to run as "Interactive  User",
    which  means  that  when  it   is  launched,  it  runs  with   the
    credentials  of  the  currently  logged  on  user.  It also allows
    Everyone to start and access it remotely.

    The purpose of this DCOM object is not documented, nor are any  of
    the methods  that it  supports.   However, by  examining the  type
    library that it includes, the methods and their parameters can  be
    examined.  One  of the methods  the VB T-SQL  debugger provides is
    the NewSPID method, which looks like this:

        HRESULT NewSPID([in] long spid,
                        [in] long pid,
                        [in] BSTR lpctstrDbName,
                        [in] short cbName,
                        [out, retval] short* nReturn);

    The purpose  of this  call is  apparently to  create a  new stored
    procedure id in  the given database,  but that's just  conjecture.
    Anyway, this method contains a classic buffer overflow, due to  an
    unchecked  call  to  sprintf  using  the  passed in lpctstrDbName.
    Passing in a  dbname over approximately  128 characters in  length
    will overwrite the stack frame.  From that point, it's  relatively
    easy to return to an address that will call into the exploit  code
    on the stack.   Just find a  "call esp" somewhere  in the  address
    space, and return there.


SOLUTION

    Visual Studio 6.0 Professional Edition  is not affected.  A  patch
    is available to fix this vulnerability.  Please read the  Security
    Bulletin

        http://www.microsoft.com/technet/security/bulletin/ms01-018.asp

    for information on obtaining this patch.

    Remove the  Everyone:Launch and  Everyone:Access permissions  from
    the VB T-SQL Appid key under HKCR\Appid.  Restrict the permissions
    to  SYSTEM  and  Admins  only.   Determine  whether  the  VB T-SQL
    Debugger Object  is installed  on your  systems.   To do this, run
    dcomcnfg  and   look  for   it  in   the  list   of  applications.
    Alternatively, look for the registry key

        HKCR\Appid\{124765aa-7866-11cf-bf3b-00a0d10003fa}

    If it exists either remove  it, or restrict the launch  and access
    permissions specified there.  Install the hotfix from Microsoft.

    Microsoft's Hotfix:

        http://msdn.microsoft.com/vstudio/downloads/debugging/default.asp