|
Date:
====
4/8/2001
Summary:
========
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.
Details :
=======
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 does not secure
their Access database with a username and password, despite best
efforts to the contrary.
Technical 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 that does exactly this, FTPing an ASP script
that uses the file-scripting object to read the contents of the
ODBC.INI file.
Solution:
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 use contains comments that would
indicate that Windows NT 4.0 is also vulnerable to system DSN enumeration.
For administrators operating shared hosting web servers, it is 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.
We 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.
|