COMMAND

    kernel

SYSTEMS AFFECTED

    Win2000

PROBLEM

    Erik  Power   found  following.    A   vulnerability  exists    in
    Microsoft's  default  security  settings  for  ODBC  data sources.
    Under certain circumstances,  this vulnerability could  contribute
    to unauthorized  users gaining  access to  one or  more databases.
    For those  of us  that operate  shared web  hosting servers,  this
    problem is of particular importance.

    Any user  with access  to the  machine (e.g.  a customer  with FTP
    access to their site  content) can use standard  scripting methods
    to enumerate the  entire list of  system DSNs on  the server.   If
    any of the DSNs  point to a data  source that is not  secured by a
    user name and password, this data source will become available  to
    anyone with  the DSN  name.   A good  example would  be a  hosting
    customer  that  doesn't  secure  their  Access  database  with   a
    username and password, despite best efforts to the contrary.

    By  default,  Windows  2000  stores  system DSN information in two
    locations: a file called  ODBC.INI located in %systemroot%  and in
    the  registry   under   HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI.
    The default permissions on both the file and in the registry  have
    the local  machine's "users"  group added  with read  permissions.
    On an IIS server,  the anonymous IUSR account  is a member of  the
    "users"  group.   Any  user  capable  of  uploading  a  script can
    enumerate  a  list  of  DSNs  using  standard scripting methods to
    access  either  the  registry  or  the  ODBC.INI  file  under  the
    authentication  of  the  IUSR  account.   Macromedia  produces   a
    product for beginning  web developers called  Dreamweaver Ultradev
    which does exactly this, FTP-ing an ASP script that uses the  file
    scripting object to read the contents of the ODBC.INI file.

    Web  applications  making  use  of  DSNs  do  so  by accessing the
    registry--the  ODBC.INI   file  is   not  used.    Removing   read
    permissions for the  "users" group from  this file has  no adverse
    affects  on  web  sites  that  use  DSNs  to  access  various data
    sources.  In  the registry, the  only locations where  the "users"
    group  needs  read  permissions  is  on  each  individual sub-tree
    created for each DSN.

    The  script  Macromedia's  product  uses  contains  comments which
    would indicate that  Windows NT 4.0  is also vulnerable  to system
    DSN enumeration,  however we  don't have  an NT  4.0 box available
    for testing.

SOLUTION

    The  resolution  is  to  remove  read  permissions for the "users"
    group on the  ODBC.INI tree and  add read permissions  only to the
    sub-trees that exist for each DSN.

    For  administrators  operating  shared  hosting  web  servers,  we
    highly  recommend  that  you  lock  down  the security on both the
    ODBC.INI file  and associated  registry settings.   Microsoft  has
    thus  far  been  unwilling  to  acknowledge  this  as  a bona-fide
    security vulnerability.  This problem  is not mentioned in any  of
    Microsoft's security documentation.   However, that the  anonymous
    IUSR  account  (or  any  standard  user  account, for that matter)
    should NOT  be allowed  to obtain  information as  meaningful as a
    complete list of system DSNs.