Microsoft Corporation
1997
Recent articles in the computer press claim that new security problems were introduced with the Microsoft® ODBC 3.0 software release. Microsoft's ODBC (Open Database Connectivity) 3.0 conforms to the ODBC database access standard administered The Open Group (formerly X/Open and the Open Software Foundation).
These erroneous articles are based on a misunderstanding of a troubleshooting feature that has existed since Microsoft's ODBC 2.0 release. This "call tracing" feature was implemented at the request of developers and support organizations to allow the logging of information to a file for troubleshooting. Since tracing tools can be used to decode sensitive information under certain circumstances, this feature and security concerns are discussed in the ODBC Programmers Reference.
A variety of methods are available for enhancing security when using ODBC for client/server database connections. Applications can use secure methods for authenticating users, instead of sending plain text logon information that is vulnerable to tracing and sniffing. Programming methods are available to prevent tracing. Sites requiring enhanced security can use new ODBC components that obscure logon information and provide additional security features.
Sensible security policies can be combined with these technical methods to provide secure data access using ODBC. Microsoft takes security issues seriously and will aggressively address any concerns regarding the use of debugging and troubleshooting tools.
Application developers must thoroughly understand the use of ODBC development techniques for developing secure applications.
Database system administrators, network security specialists, and troubleshooters for database applications should understand security issues regarding communications protocols, including ODBC and ODBC call tracing.
End users of Microsoft Office and other applications should simply follow the security guidelines outlined for their organizations.
Microsoft Press books:
Inside ODBC, by Kyle Geiger
Microsoft ODBC 2.0 Programmer's Reference and SDK Guide
Microsoft ODBC 3.0 Programmer's Reference
ODBC 3.0 Software Developers Kit
The ODBC Web site (http://www.microsoft.com/data) also has other information, including frequently asked questions, white papers, and access to the Microsoft Knowledge Base. This support database is produced by Microsoft Product Support Services and provides information about Microsoft products, including problem reports, troubleshooting tips, fixlists, and general information.
Microsoft sponsors several ODBC-specific UseNet newsgroups. See the ODBC Web site for details for access information.
Check the Web site for updates about enhanced security features in Microsoft's ODBC.
Call tracing enables troubleshooting information to be logged to a file on the client machine. It can be turned on using the ODBC Driver Manager application in the Control Panel. Trace entries are in text format and include parameters such as the connect string. Some drivers include the user ID and password in this string for authentication on the server.
The call tracing feature is off by default. Under normal circumstances a developer or support technician turns on tracing, runs the application that accesses the database, and then examines the trace file. When tracing is enabled, it causes severe performance degradation and can quickly generate a huge log file.
A malicious user would have to take extreme measures to obtain authentication information using ODBC tracing. First, an assumption is made that applications don't use security methods to encrypt logon information. Then the malicious user must have physical access to the machine, enable call tracing, and wait for a legitimate user to log on to a secured database. Another assumption is made that the legitimate user doesn't notice performance slowing to a crawl and investigate the problem. The malicious user would need to share the file on the net or return to the machine to examine the file. It would probably be far easier for a malicious user to sniff the network.
ODBC trace information can be obtained by other methods, including the ODBC Spy utility shipped in the ODBC SDK since version 2.0, third-party ODBC debugging tools which include call tracing, and debuggers that can intercept calls to the ODBC Driver Manager and inspect parameters.
Applications using Windows NT® security do not pass user IDs and passwords across ODBC connections. For example, Microsoft SQL Server® can be configured to use "integrated" NT security. IBM's DB/2 has a similar configuration. Applications certified to carry the BackOffice logo have the option to use NT security.
Some applications implement their own security mechanisms on top of ODBC. In this case user IDs and passwords are encrypted before being transmitted via ODBC. Troubleshooting tools capturing the ODBC calls only see encrypted information.
Applications should prevent tracing of any sensitive commands by setting the connection attribute SQL_ATTR_TRACE to SQL_OPT_TRACE_OFF, and then re-enable tracing by setting SQL_ATTR_TRACE to SQL_OPT_TRACE_ON afterwards. Tracing can be completely disabled by leaving SQL_ATTR_TRACE off.
On Windows 95® or Windows NT the trace DLL, odbctrac.dll, can simply be deleted. This should be done as part of an automated log-on script, as future ODBC installations may reinstall the DLL.
On Windows NT, registry security and default registry settings can be employed to disallow modification of the trace options for all users except for administrators. Details of these procedures will be made available in the Microsoft Knowledge Base (see the Knowledge Base bin of the MSDN™ Library, or visit http://support.microsoft.com/support/ for the latest versions.).