MDAC 2.5 SDK - Technical Articles
Articles in the computer press claim that new security problems were introduced with the Microsoft ODBC 3.0 software release. Microsoft ODBC (Open Database Connectivity) 3.0 and later conforms to the ODBC database access standard administered by 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 the Microsoft 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 Programmer's 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 3.0 Programmer's Reference
From the Microsoft Data Access Web site: http://www.microsoft.com/data/
You can download the MDAC SDK, which includes the Microsoft ODBC 3.51 Programmer's Reference.
The ODBC pages on the Data Access Web site have other information, such as white papers.
Microsoft Knowledge Base
You can also find ODBC information in the Microsoft Knowledge Base. This support database is produced by Microsoft Technical Support and provides information about Microsoft products, including problem reports, troubleshooting tips, fix lists, and general information.
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 use of the tracing utility in the ODBC Data Source Administrator; third-party ODBC debugging tools, which include call tracing; and debuggers, which 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" Windows NT security. IBM DB/2 has a similar configuration. Applications certified to carry the BackOffice logo have the option to use Windows 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 Sources for Further Information).