Re: Adding some random characters to Oracle password

From: Jonathan Leffler <jleffler_at_earthlink.net>
Date: Tue, 02 Nov 2004 04:31:46 GMT
Message-ID: <41870DAF.6080207@earthlink.net>

Pete Finnigan wrote:

> Just out of interest did you check program and module in v$session or
> just program? - I don't expect the end result to change but I would be
> interested to know. For SQL*Plus on windows i get
> 
> SQL> select module,program from v$session
>   2  where username=user;
> 
> MODULE
> ----------------------------------------------
> PROGRAM
> ----------------------------------------------
> SQL*Plus
> sqlplusw.exe
> 
> 
> SQL> 

Just out of curiosity - or maybe cynicism - what happens if a client program identifies itself the same way as SQL*Plus? Or, more likely, someone writes a tool somewhat similar to SQL*Plus that can execute more or less arbitrary SQL commands, but carefully identify the program as 'not SQL*Plus' and hence trustworthy (or more trustworthy).   Can someone deduce which applications are trusted, work out how the trusted applications identify themselves, and create their own executable which identifies itself the same way but is actually totally untrustworthy? How much effort is involved (not that effort required counts for much compared with simple feasibility in matters of security)?

Obviously, in practice SQL*Plus is the loose cannonball and is the program that gets constrained first (so my original question is of limited interest), but what about the trusted programs. How hard is to work out how trusted programs identify themselves and mimic a trusted program?

(If it's any consolation, the Informix equivalent of SQL*Plus is DB-Access and it is just as much a loose cannonball as SQL*Plus.)

> Howard J. Rogers <hjr_at_dizwell.com> writes

>>OK, one quick test later.
>>
>>Knock up a silly application in MS Access that links to the EMP table. When
>>you query it in V$SESSION, it is listed as program MSACCESS.EXE.
>>
>>Drop to the operating system and rename c:\program
>>files\etc\etc\etc\MSACCESS.EXE HJR.EXE.
>>
>>Re-run the silly MS Access app: V$SESSION now sees it as program HJR.EXE.
>>
>>Pete's right in other words: if the application is instrumented to reveal
>>its name, then merely renaming the executable doesn't do anything. But if it
>>the application is "oracle blind", and doesn't know/care to reveal its
>>identity via dbms_application_info, then a simple rename will fool the
>>system.
>>
>>Regarding the original paper, that's not an issue, since both SQL*Plus and
>>iSQL*Plus instrument properly. But ODBC applications certainly don't.
>>
>>
>>"Pete Finnigan" <plsql_at_petefinnigan.com> wrote:
>>>>Excellent question. You realise it will require some testing and research
>>>>won't you!? (In other words, I'll get back to you on that one!!).
>>>>But it will appear as a new paragraph at the end of the existing paper,
>>>>because it's such a good issue to address.
>>>>
>>>>It is because people ask good questions that we (together) learn good
>>>>stuff.
>>>
>>>I answered this question over a year ago in relation to SQL*Plus in my
>>>newsletter http://www.petefinnigan.com/news_letter_001.pdf - In there I
>>>renamed the SQL*Plus binary on the client and on the server and the
>>>values in v$session did not change. In other words Oracle networking
>>>still knew it was SQL*Plus even though the binary is now called
>>>"hacker". I guess this is because SQL*Plus identifies itself internally
>>>to the network stack. I don't know if the same will work if you use a
>>>third party application unless that application uses
>>>dbms_application_info to set up values.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Received on Mon Nov 01 2004 - 22:31:46 CST