Re: Microsoft's New ODBC Admin

In <3346EE15.532D_at_exesolutions.com> "Daniel A. Morgan" <dmorgan_at_execsolutions.com> wrote:
> We have downloaded from Microsoft their version 3 ODBC admin tool and
> determined that it completely compromises security for any and all
> connected applications.
>
> If you would like to test this yourself perform the following on a test
> machine. Do NOT compromise your corporate security.
>
> 1. Download the version 3 ODBC Admin from www.microsoft.com
> 2. Install and configure
> 3. Run trace
> 4. Log into any "secure"; instance
> 5. Take a good look at the trace
> 6. Observe that Microsoft has compromised your security
>
> Once again Microsoft has demonstrated an amateurish level of testing and
> understanding of the needs of the corporate development environment.
>
> Needless to say this has been reported to the appropriate publications.
>
> Daniel A. Morgan

  I don't know which security was compromised by odbc from your opinion and why   it demonstrated an amateurish level of testing and understanding of Microsoft.   What will be a professional view toward this issue and its solution? Microsoft   ODBC 3.0 spec. parllels with the proferssional work of ANSI CLI and X/Open   XDBC. the security is compromised in the ODBC (or ANSI CLI or XDBC) spec. or   ODBC implementations(driver manager or drivers) or an ODBC application   implementation??  

  The odbc trace facility (and odbc in general), as far as i know, is impossible   to be used for breaking any *real* secure system unless the underneath secure   system itself is poorly designed and includes flaws which can be utilized not only by odbc but also by non-odbc program.  

  Which security system you are using? what is the security policy of it?   If the system's security was so easily broken by ODBC, it is likely to be its   (i.e. the system's) problem. Simply replace this crap system by a secure   one may solve this problem. I see many beginners claim odbc break their   security system but in fact what were happened is either they are using   a particular odbc driver implementation which doesn't provide data   protection(e.g. transfore un-encrypted data on wire) or simply their   system and datasource were original not secure at all as they thought   (i.e. odbc doesn't break but uncover the unsecure nature of their "security")   One good example is, many beginners, after using odbc, realized ms-access,   windows 3.x, win95, etc. are unsecure by design (i.e. they are not designed   under such requirement).  

  Many beginners complain about odbc trace or spy logs user's uid and password   (as well as application data and message text) in clear text form. However, is   doesn not create a new security problem(if it was one). Displaying and logging   password and other application data/message in clear text under requirement of   original(or privileged) user doesn't seem to be a security problem at all.   A well known example is: most unix system have a trace (or truss on SVR4 and   strace on linux) tool. you can use it to trace shell, telnet, ftp, etc.   processes (and their child processes) if they were invoked by youself (or   other, if you are a superuser) and display (or log into a file) the password   in clear text no matter the password will be encrypt or not by the traced   process.  

  Here is how I use truss on solaris to trace a csh program and its child   telnet process to catch the password used in login the telnet session.  

1. get csh pid

        % ps -u odbc  

        PID TTY      TIME COMD
      11129 pts/39   0:01 csh
        ....
 

  2. invoke the truss tool  

        % truss -o t.log -f -t read -p 11129 &  

        % telnet linux1
        login: odbc
        odbc's Password:        (type in my password "public1" here)
        Last unsuccessful login: Mon Apr  7 10:55:07 PDT 1997 on /dev/pts/9 from
        solaris2
        ....
 

  3. the t.log file will include following content  

        ....
        5942:   read(0, " o", 1024)                             = 1
        5942:   read(0, " d", 1024)                             = 1
        5942:   read(0, " b", 1024)                             = 1
        5942:   read(0, " c", 1024)                             = 1
        5942:   read(0, "\r", 1024)                             = 1
        5942:   read(0, " p", 1024)                             = 1
        5942:   read(0, " u", 1024)                             = 1
        5942:   read(0, " b", 1024)                             = 1
        5942:   read(0, " l", 1024)                             = 1
        5942:   read(0, " i", 1024)                             = 1
        5942:   read(0, " c", 1024)                             = 1
        5942:   read(0, " 1", 1024)                             = 1
        5942:   read(0, "\r", 1024)                             = 1
        ....
 

  Here, you can see both my login name (odbc) and password (public1)   of the telnet session was logged as clear text right after they were   read from the terminal (i.e. stdin).  

  Here, what I did is tracing my own process. If I am a superuser, I can   trace any user's telnet and even login session using this tool.  

  This well known *functionallity* or *feature* is exactly like what   you have seen on ODBC trace (or spy) and has never been thought as a   security problem(no matter the password in trace file is in clear text or   not). Because only youself (in fact, only the effect user of the   process and superuser) is allowed to perform this system call tracing   on unix. It is same on ODBC case, only youself or system administr (or   someone else who has getten permission from you) can do is tracing on   *your* ODBC application *if you have set up properly*. As long as you   not give your password to someone else, not give unnecessary permission   (such as to modify your ODBC.INI file or system registy in your name) to   other untrusted people, not allow an untrusted person to read that   logging file(you should know how to use umask and chmod) or email this   file to him/her, make sure noone is videocameraing your keyboard typing,   not install and use an application from an untrusted provider(such as   make sure Microsoft driver manager or admin tracing facility only log   the password to a local file belong to you rather than send it back to   their office by email or broadcasting it over the network behind the   screen :)), etc. you needn't worry about your password has been, *under   your own requirement*, log from your finger into a file specified by you.   If you say "i am using windows(3.1, 95 and maybe NT) or dos, os/2, mac,   etc. or some toy systems without such protection from system level",   than, the solution is simply lock the mechine when you leave or encrypt   (or move away) everything you want to be protected (include ODBC.INI or   registory, ODBC driver manager, ODBC driver, ODBC application, etc. and,   more important, the system and booting program themselves !!!) and decrypt   (or copy back) before using them.  

  As a final words, I like to say, Microsoft has demonstrated they have   started to accept the real needs of the corporate development environment   beyond their original amateurish level of testing and understanding. I.e.   they realized that simply hidding password as well as other application   data and message text from tracing log file (like what they partially   did in 2.0 manager and admin tool) is unnecessary and dosen't provide any   real security and protection.  

  Ke Received on Mon Apr 07 1997 - 00:00:00 CDT