An Opinion About the Security Risks of Allowing ODBC 3.0 in Your Company.
A major security flaw has been identified with the release of Microsoft's new implementation of Open Database Connectivity (ODBC) known as version 3.0. The ODBC 3.0 Driver Manager that is automatically installed with Microsoft's Office 97 can compromise otherwise secure user identifications and passwords.
In the late 1980s, major vendors of SQL-based products responded to the needs of database developers for a portable SQL application programming interface (API) by forming the SQL Access Group (SAG). SAG defined a specification that has served as the basis for Microsoft's ODBC. Since its inception, a large number of drivers have been developed for ODBC, both by Microsoft and other software vendors, and it has quickly become the de facto standard for SQL APIs. ODBC is now the standard way to connect front-end development tools, such as Visual Basic and PowerBuilder, to SQL back-end databases, such as Oracle, Informix, and SQL Server. Microsoft extended the basic functions defined in the SAG specification and supplies the ODBC Driver Manager for its Windows operating systems. This ODBC Driver Manager coordinates access to ODBC drivers and their associated data sources within Microsoft's Windows environment. It is this ODBC Driver Manager that is now putting systems based upon Windows and ODBC at risk.
Up until 1997, and the release of ODBC version 3.0, ODBC has been a stable and reasonably secure environment from which database vendors could create their systems. Front-end tool developers could write their products, and application developers could build applications with the knowledge that only the most technically proficient IS professionals could snoop out passwords. The ODBC Driver Manager supplied the functionality to use ODBC in Microsoft's Windows environments and even provided a trace facility for debugging.
The security issue that has been identified relates specifically to Microsoft's new implementation of ODBC version 3.0 that ships with, and is automatically installed by, Microsoft Office 97. This implementation of ODBC will also, presumably, be made available in a wide range of other products by both Microsoft and other vendors. The new ODBC Driver Manager includes a call-tracing facility that allows for, not only the tracing of all function calls made from the client to the server, but also, unfortunately, the tracing of the user's identification and password.
In previous versions of the ODBC Driver Manager, the tracing facility has traced ODBC function calls but has not traced user passwords. An example of an ODBC version 2.x trace can be seen in Listing 1 (see page 100).
In Listing 1, you can see on the fourth line that the user's identification has been indicated as "uid=rtl3322" but the password has been kept secure by substituting a string of asterisks (pwd=*******). In ODBC version 3.0 the trace has been modified in a manner that compromises system security. In Listing 2 (see page 102), you can clearly see this compromise by looking at the line that contains "Oracle;DBQ=db1.world;UID=rtl3322;PWD=bcs1100." This single line in the log file clearly indicates that an Oracle system with host name DB1 can be accessed by typing in user ID "rtl3322" with password "bcs1100": The equivalent SQL Plus log-on would be "rtl3322/ bcs1100@db1."
What makes this problem particularly insidious is the fact that the log file can be created by anyone with either physical or network access to a machine; within any application residing on the client machine or a server that has access to the client machine; or with an ActiveX component. An application that runs afterward can turn tracing on or off at will. The problem is that once any one application or process turns it on it is "on" for all applications. Further, the log file can be created on the machine performing the trace, on any machine connected to the machine performing the trace, or sent across the Internet to any other site. Microsoft says that 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 above statement contains several errors, however. First the trace file is, by default, on the client machine, but it does not have to be. The file can be written to any client or server that the client machine accesses and can even be sent across the Internet. The second error is the reference to "some drivers." The trace function is in the Windows ODBC Manager, and testing has not identified any driver that does not trace security information.
In response to published articles about the breach in ODBC security Microsoft posted a page on their Internet site titled "Understanding ODBC Security Issues" (www.microsoft.com/odbc/default.htm). Table 1 (see page 100) explores each of Microsoft's points and my response to its validity.
The major question that has been asked of me since the discovery of this security breach has been "Why?" Why would anyone render insecure an API used to build secure systems? What possible value could there be in a trace that logs the user's password? In my opinion, the answer can be found in the following quote from the Trace File page in the ODBC SDK help file, "Caution: User names and passwords are logged in ODBC 3.0 tracing. ODBC tracing does not ensure secured access to user names and passwords." Obviously the change was made intentionally without consideration for its implications for the user community.
| Microsoft | Dan Morgan's Response |
|---|---|
| Applications using NT security do not pass user IDs and passwords across ODBC connections | A thorough testing of the Driver Manager version 3.0 on Windows 95, Windows NT 3.51, and Windows NT 4.0 demonstrated that all of these systems are compromised revealing user IDs and passwords. |
| 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 | The fact that something may be encrypted before being passed to the ODBC Driver Manager does not prevent a malicious person from writing a few lines of Visual Basic code and passing the encrypted password directly to the application's back end. |
| Applications should prevent tracing of any sensitive commands by setting connection attributes. | This argument assumes that the vendor of every ODBC based application is willing to recompile every preexisting application. Even if newly developed applications turn the tracing facility off, there is no protection for applications already installed and running. |
| Tracing can be completely disabled by leaving SQL_ATTR_TRACE off. | This is not true. Any application can turn ODBC tracing on and off at will. This can be done with a single line of Visual Basic code, it can be done by an ActiveX control or a DLL, and it can be done by anyone with physical or network access to a client machine. You could write an application that starts up and immediately turns tracing off. A completely different process could turn it on and compromise the system. |
| On Windows 95 or Windows NT, the trace DLL, odbctrac.dll can simply be deleted. | It can also simply be placed back onto the machine. Not only can this be done intentionally, it can be done inadvertently and without warning by any product, such as Microsoft's Office 97 that installs this DLL as part of its installation routine. |
| On Windows NT, registry security and default registry settings can be employed to disallow modification of the trace options. | This partial solution only affects users with Windows NT, leaving those with Windows 3.1 and Windows 95 insecure. It also does not address the fact that it requires a hands-on modification of every PC in a company. |
| A malicious user would have to take extreme measures to obtain authentication information using ODBC tracing. | This is, without a doubt, the most upsetting statement made by Microsoft. The number of mouse clicks required to initiate an ODBC trace is the same number required to create a new document in Microsoft Word. I doubt any reasonable person would consider five mouse clicks an "extreme measure." |
SQLAllocEnv(phenv004A3D80); SQLAllocConnect(henv004A3D80, phdbc004A45E4); SQLDriverConnect(hdbc004A45E4, hwnd 00000000, "DSN=JigTool32 Oracle;DBQ=db1.world;UID=RTL3322;PWD*******", 58, szConnStrOut, 256, pcbConnStrOut, 1); SQLGetInfo(hdbc004A45E4, 17, rgbInfoValue, 26, pcbInfoValue); SQLGetInfo(hdbc004A45E4, 18, rgbInfoValue, 26, pcbInfoValue); SQLGetInfo(hdbc004A45E4, 21, rgbInfoValue, 2, pcbInfoValue); SQLAllocStmt(hdbc004A45E4, phstmt004A70C4); SQLFreeStmt(hstmt004A70C4, 1); SQLAllocStmt(hbdc004A45E4, phstmt004A2588); SQLBindCol(hstmt004A2588, 1, 5, rgbValue, 1, pcbValue); SQLBindCol(hstmt004A2588, 2, 5, rgbValue, 1, pcbValue); SQLBindCol(hstmt004A2588, 3, 5, rgbValue, 1, pcbValue); SQLBindCol(hstmt004A2588, 4, 5, rgbValue, 1, pcbValue); SQLExecDirect(hstmt004A2588, "SELECT CANREAD, CANADD, CANUPDATE, CANDELETE FROM JIGTOOL.SECURITY Where USERID = 'RTL3322'", 93); SQLFetch(hstmt004A2588); SQLFreeStmt(hstmt004A2588, 2); SQLFreeStmt(hstmt004A2588, 1); SQLDisconnect(hdbc004A45E4);
VB32 81:72 ENTER SQLAllocEnv HENV* 0x00184538 VB32 81:72 ENTER SQLAllocConnect HENV 0x00a81ca0 HDBC * 0x0018453c VB32 81:72 EXIT SQLAllocConnect with return code 0 (SQL_SUCCESS) HENV 0x00a81ca0 HDBC * 0x0018453c ( 0x00a81e20) VB32 81:72 ENTER SQLDriverConnectW HDBC 0x00a81e20 HWND 0x00000000 WCHAR * 0x00a81ed0 [116]"DSN=JigTool32 Oracle;DBQ=db1.world;UID=rt13322;PWD=bcs1100" SWORD 116 WCHAR * 0x00a72920 SWORD 512 SWORD * 0x0012f982 UWORD 1 <SQL_DRIVER_COMPLETE>
What did you think of this article? Send a letter to the editor.