Hello all,
        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.

        Summary: 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.

        Details: 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.

        Remedy: 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 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.

        The script Macromedia's product uses contains comments which
would indicate that Windows NT 4.0 is also vulnerable to system DSN
enumeration, however I don't have an NT 4.0 box available for testing.
For administrators operating shared hosting web servers, I 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. I think
you'll agree, 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. Thanks to
Russ for pointing out the potential for scripted access to the registry.

Yours,

______________________________________________________

Erik P. Power Site Specific, Inc.
eriksitespecific.net 1402 3rd Ave. Suite 1230
Voice: (206) 652-0677 Seattle, WA 98101
Fax: (206) 652-0676 http://www.sitespecific.net
______________________________________________________

----------------------------------------------------------------------------
Delivery co-sponsored by Trend Micro
======================================
TREND MICRO REAL-TIME VIRUS ALERTS
If you would like to know about a virus outbreak before CNN and ZDNet get
Trend Micro Virus Info Feed FREE. Simply copy and paste a small piece of
code to give your visitors a real-time top 10 list and the latest virus
advisories. Setup takes just 10 minutes and requires no server-side code on
your Web site. All content is updated automatically from Trend Micro's Web
site.
http://www.antivirus.com/banners/tracking.asp?si\8bi#7&ul=/syndication/
vinfo/
----------------------------------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]