Re: Security question: sqlplus and the ps cmd on Unix

From: Tony Jambu <aaj_at_phantom.telecom.com.au>
Date: 1995/04/03
Message-ID: <3lo0kt$nih_at_newsserver.trl.OZ.AU>

In article <1995Mar30.003350.19816_at_scammell.ecos.tne.oz.au>, iap_at_scammell.ecos.tne.oz.au (Ian Parkin) writes:
> Did anyone archive the last thread on this subject ?
>
> When this subject was last being discussed I had time to travel halfway
> across
> the planet, enjpy a few stop overs en route, find a job, move into a
> apartment
> and get an internet connection at home (ie it lasted many months) !
>
> If there is an archive could someone please save us all some bandwidth and
> post a summary ?
>
> If this isn't in the FAQ, perhaps it should be ? Perhaps we should all send
> some postcards to the FAQ maintainers daughter and get him to add it in.

I wrote a paper on security and one of its topic was on 'ps'. I actually posted
an excerpt to a few people directly on the net. FOr the benefit of the rest, I am enclosing it here. Please be warned that it was written about a year ago and is already out of date. It doesnot profess to provide the best or only solution. It gives you some ideas. Thanks to those overs the years on the Net
that help in its discussion.

---

TOPIC 1: Hiding Username/Password from ‘ps’s

If a program is called or executed on a UNIX platform with arguments supplied on the command line, then it is possible for another UNIX user to see the name of the program and its arguments using the ‘ps’ command. This section will show how this is possible and suggests various methods to overcome it in both the AT&T and Berkeley UNIX operating system.

Oracle programs require the user to enter either their Oracle username and password interactively or on the command line. For batch programs or programs that are required to be executed from cron, entering the username and password interactively is not possible; they need to be entered on the same command line. This has to be hardcoded in the shell script or program. It is obviously insecure as the ‘ps’ command can display both the username and password.

For example, assume that we have a program called ‘progname’ and it requires 3 arguments. ‘progname’ is executed by user A and is left to run. User B then executes a ‘ps’ to show who is executing ‘progname’ program on the UNIX machine.

SUN O/S (Berkeley UNIX)
ps -ax | grep progname

  PID TT STAT TIME COMMAND
18748 p0 S 0:00 progname arg1 arg2 arg3

HP-UX (AT&T UNIX)
ps -ef | grep progname

 UID PID PPID C STIME TTY TIME COMMAND  aaj 26196 26111 0 23:01:50 ttyv9 0:00 progname arg1 arg2 arg3

Now if the program was sqlplus and was executed using the command "sqlplus SYSTEM/MANAGER _at_script" we would see that the user’s name is SYSTEM and its password is MANAGER.

 UID PID PPID C STIME TTY TIME COMMAND  aaj 26211 26199 0 23:03:20 ttyv9 0:00 sqlplus SYSTEM/MANAGER _at_script

This ‘characteristic’ will depend on the version of UNIX and the Oracle program, and more so on versions of UNIX based on the AT&T UNIX. Over the years, Oracle has been modifying their programs to avoid this situation. However, this is dependent on the implementation of the operation system and the porting team.

To avoid such a security risk, the following are suggested solutions.

SOLUTION 1: Blanking out argv

When a program is executed, its name, arguments and other relevant information are stored in the process table. ‘ps’ will query this process table. With ‘C’ programs, it is possible to blank or erase the arguments from the process table. This is achieved by coding the argv variable in ‘C’ to be blank.

for (i = 1; i < argc; i++)

    memset(argv[i], 0, strlen(argv[i]));

In fact, only the first argument, argv(1) is required to be blanked out. Using the ‘progname’ program example again with argv set to be blank, ‘ps’ generates the following output.

SUN O/S (Berkeley UNIX)

ps -ax | grep progname
  PID TT STAT TIME COMMAND
18652 p0 IW 0:00 arg2 arg3 (progname)

HP-UX (AT&T UNIX) ps -ef | grep progname
 UID PID PPID C STIME TTY TIME COMMAND  aaj 26235 26111 0 23:07:54 ttyv9 0:00 progname arg1 arg2 arg3

Notice that on HP-UX (or any derivative of AT&T UNIX), blanking out argv(1) has no effect. You are still able to see all its arguments. This is due to the way AT&T UNIX implements its process list and the permissions associated with it. Programs are not permitted to modify the process list. Therefore Oracle programs are unable to hide the username and password on AT&T UNIX version of the operating system.

All is not lost. It is still possible to hide the arguments from the ‘ps’ program by left padding the first argument with lots of spaces. The first argument needs to be enclosed in quotes with lots of leading spaces. The effect of having 10 spaces is shown below to demonstrate the effect. You would have to pad sufficient spaces to hide the argument from the ps display.

NORMAL:
$ sqlplus SYSTEM/MANAGER _at_tmp
$ oracle 26782 26522 0 03:26:29 ttyv5 0:00 sqlplus SYSTEM/MANAGER _at_tmp

Padded with 10 spaces:
sqlplus " SYSTEM/MANAGER" _at_tmp $ oracle 26760 26522 1 03:24:49 ttyv5 0:00 sqlplus .......... SYSTEM/MANAGER _at_tmp

While this approach is messy, it is effective.

PROS:
         Effective on derivatives of Berkeley UNIX

CONS:

 	Dependent on version of UNIX.
 	Left padding the first argument with spaces is messy.
 	Not possible to modify Oracle’s binaries.

SOLUTION 2: Use of OPS$LOGIN

The use of OPS$LOGIN or proxy logins is the most secure approach to running an Oracle batch job. This does not require the typing of the username and password interactively nor its hard-coding in a shell script.

An Oracle batch user may be specifically created at the UNIX operating system, say ‘batchuser’, with an unknown UNIX password. Batch jobs may then be scheduled via the ‘cron’ or ‘at’ utility by submitting these jobs to root to have them appended to the crontab entry file.

batchuser:*:221:101:Oracle Batch user:/tmp:/usr/bin/sh /etc/passwd entry

To prevent other UNIX users from using this Oracle OPS$batchuser user account to interactively logon to the database, the Oracle account should be created with no password but be authenticated externally, that is, at the UNIX operating system.

sql> create user OPS$batchuser identified externally;

If there is a requirement to have the Oracle authentication prefix set to a value other than ‘OPS$’, then the INIT.ORA parameter, OS_AUTHENT_PREFIX needs to be defined.

To prevent other security issues relating to remote user access, ensure that the INIT.ORA parameter, REMOTE_OS_AUTHENT is set to FALSE.

With the above approach, you now have a secure method of executing batch jobs without the need to specify the pseudo Oracle user’s name and password on a command line and no UNIX user is able to logon interactively to the database as the batch user because the Oracle account needs to be authenticated at the operating system level, which in turn does not have a UNIX password.

PROS:

 	Easy to implement
 	Secure

CONS:
 	Still has some possible security weakness such as remote logins from an

unauthorised
machine .

         Need to implement proxy logins.

SOLUTION 3: Use of ‘here document’ <<

Most UNIX shells, for example, Bourne and c-shell have a feature called ‘here document’, represented by two less than symbols, ‘<<‘. This feature allows the shell to read the following shell input lines from standard input upto the line terminated by the end-of-file terminator. The end-of-file terminator is the word or string following the ‘<<‘ characters. In the example below, it is the EOF string.

sqlplus <<EOF
system/manager
_at_ins_txn1
EOF A ‘ps’ will not be able to see the lines between the end-of- file terminators. A drawback of this approach is the need to hard code the username and password into a shell script. This may be overcome by setting up shell variable with not so obvious name like, ‘DEPTH=orauser’ and ‘COLOUR=orapassword’.

sqlplus <<EOF
$DEPTH/$COLOUR
_at_ins_txn1
EOF Where and when the above shell variables are set is left to the reader to decide. A technique that can be use is the utility, get_orapasswd which given an Oracle user, will determine its password.

sqlplus <<EOF
system/`get_orapasswd system`
_at_ins_txn1
EOF PROS:
         Easy to implement

CONS:
         May have to hard code the password in the shell script.

SOLUTION 4: Rewrite ‘ps’

On some UNIX boxes there are two versions of the ‘ps’ commands, one being the full featured version for privilege users and the other ‘plain’ version for the public. If this is not the case for your box, it is possible to write a local version of ‘ps’ in ‘C’ to strip out any options that may be regarded as intrusive and then pass on the other options to the ‘ps’ routine.

PROS:
         Secure

CONS:
         Non standard ‘ps’ command

 Reference: "Oracle Security In A UNIX Environment: Part 1’, Tony Jambu - IOUG Select magazine
Volume I Issue I 1993,.
 Reference: "Surviving With Oracle in a UNIX Environment" by Tony Jambu, International Oracle
User Week 1992.

-- 
 _____       ________ / ___ |Tony Jambu, Database Consultant
  /_  _        /_ __ /      |Wizard Consulting,Aust (ACN 065934778)
 /(_)/ )(_/ \_/(///(/_)/_(  |CIS: 100250.2003_at_compuserve.com FAX: +61-3-4163559
 \_______/                  |EMAIL:TJambu_at_wizard.com.au PHONE: +61-3-4122905

Received on Mon Apr 03 1995 - 00:00:00 CEST