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
 

  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 its(i.e. the   system's) problem before ODBC. Simply replace this crap system by a secure   one may solve this problem.  

  On the other hand, displaying and logging password 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 trace 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 umask work) 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, Once again 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   protection.  

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