COMMAND

    EMURL

SYSTEMS AFFECTED

    Seattle Labs EMURL 2.0

PROBLEM

    Oisin  Grehan  found  following.   In  the  course  of  evaluating
    different "hotmail in  a box" type  packages, he has  discovered a
    potentially dangerous misconfiguration  in Seattle Labs  Emurl 2.0
    package (not aware  if the problem  exists in earlier  versions as
    they were  not tested).   The problem  lies around  the (ab)use of
    Scripting.FileSystemObject  and  the  fact  that  Emurl places any
    attachments that you receive  via email into an  easily accessible
    (via  http)  directory  that  is  marked  Scriptable.   It  is not
    possible to  mark this  directory for  Read access  only as  it is
    beneath the Web's root (which needs to be Scriptable) and is  thus
    inheriting  this  permission.  This  directory's  location  is NOT
    configurable by any INI directives in Emurl.

SOLUTION

    The   only    solution    at   this    time    is   to     disable
    Scripting.FileSystemObject.     You  can  completely  disable this
    object or  selectively allow  instantiation for  different virtual
    webs by  use of  permissions on  it's registry  key. For selective
    usage  with  virtual  webs  you  should  be using different IUSR_*
    accounts for each virtual web.  Open regedt32 and open the key

        [HKEY_CLASSES_ROOT\Scripting.FileSystemObject]

    or

        [HKEY_LOCAL_MACHINE\Software\Classes\Scripting.FileSystemObject]

    (they are the same  reference).  Now click  Security, Permissions.
    You should be presented with a dialog box similar to a file  perms
    one.  Remove  "Everyone Read" from  the list and  click OK.   That
    should close down _most_ of  the harmful things possible via  this
    hole.  This is NOT a  complete fix as there are many  other things
    you  can  do  with  an  ASP  page if you're competent enough, that
    includes  download/reading  files  (via  SSI,  if parent paths are
    enabled) from known or guessed locations on the drive.