Is it possible to hide process args from 'ps -ef'??
Helge Egelund Rasmussen
command line, ie :
$ sqlplus scott/tiger
This is all very nice, BUT when another user execute 'ps -ef' he/she
can see the password!
Is it possible to hide the arguments, so that they won't show up in
the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
I know that Oracle will ask for the username & password if these aren't given
as arguments, but I would prefer giving them as arguments.
Btw. I'm using SysV3 (Interactive Unix).
Helge
---
Helge E. Rasmussen . PHONE + 45 36 72 33 00 . E-mail: h...@compel.dk
Compel A/S . FAX + 45 36 72 43 00 .
Copenhagen, Denmark
Tom Armistead
I THINK this is impossible - but I'm not a kernel type - so don't quote me
on that. If you only problem is with Oracle and SQL*Plus, you can set up
Oracle accounts so that no password is entered on the command line.
Oracle stuff after this line, press 'n' to skip:
In Oracle, you can add accounts so that the user only enters '/' on the
command line, this will be accepted as username and password.
If an Oracle account of the name 'OPS$unix_user_name' exists where
unix_user_name is equal to your account name, you will connected to
that account with '/' and no password is required.
ex.
SQL> GRANT CONNECT,RESOURCE TO OPS$TOMA IDENTIFIED BY SADKJSALJK;
The password is basically just junk to keep unauthorized people from using
the account.
Now, I log into unix as toma and run sqlplus like this:
$ sqlplus /
Hope this helps...
Tom
--
Tom Armistead - Software Services - 2918 Dukeswood Dr. - Garland, Tx 75040
===========================================================================
to...@swsrv1.cirr.com {egsner,letni,ozdaltx,void}!swsrv1!toma
H. David Bonnett
In article <1991Apr17....@swsrv1.cirr.com>, to...@swsrv1.cirr.com (Tom Armistead) writes:
|> In article <14...@compel.UUCP> h...@compel.UUCP (Helge Egelund Rasmussen) writes:
|> >It is possible to give Oracle programs the username/password on the
|> >command line, ie :
|> > $ sqlplus scott/tiger
|> >
|> >This is all very nice, BUT when another user execute 'ps -ef' he/she
|> >can see the password!
|> >
|> >Is it possible to hide the arguments, so that they won't show up in
|> >the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
|> >
|> >I know that Oracle will ask for the username & password if these aren't given
|> >as arguments, but I would prefer giving them as arguments.
|> >
|> >Btw. I'm using SysV3 (Interactive Unix).
You don't say what version of Oracle you are running, but
this is handled in the sqlplus shipped with 6.0.30:
When I connect to the database through sqlplus as follows:
{trym:~ 161}=> sqlplus scott/tiger@t:HOST:oracle
SQL*Plus: Version 3.0.8.1.1 - Production on Thu Apr 18 15:57:07 1991
Copyright (c) Oracle Corporation 1979, 1989. All rights reserved.
ps e shows:
684 p1 S 0:00 sqlplus DISPLAY=trym:0.0 (etc)
No magic is needed at all.
--
-dave bonnett- Center for Seismic Studies; Arlington, VA
bon...@seismo.css.gov : All standard disclaimers apply.
Helge Egelund Rasmussen
>>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
I received a lot of replies for this question (Thanx to all!!), and the main
result (until now) is that it isn't really possible (at least not in the
general case).
The best ones so far is:
1: exec the program with a very long argument ie.
"<fullpath>//////////////////////////sqlplus scott/tiger"
The idea of this is presumably, that ps only will show the first n
characters of the argument list.
2: Modify the argv[] list in the exec'ed program after startup.
This will ofcourse be a problem with sqlplus, but might work with
'runform' (using a user exit) or "home made" applications.
My questions are now:
Will 1 above work? Even if ps won't show the arguments, it might be possible
to write a program which can read the argument list from memory. Is this
possible? If it is, then this method isn't really safe.
The problem with method 2 above is, as far as I can see, that it wouldn't
be really safe because of race conditions. Ie. sometimes a user might have
time to execute a PS in the time after the exec, and before the application
have had time to destroy the argv structure. Is this correct?
xt...@levels.sait.edu.au
> command line, ie :
> Is it possible to hide the arguments, so that they won't show up in
> the 'ps' output
What you want to do is not good. Sure you might be able to write something
which accepts command line arguments, hides them and then calls Oracle; but
there will always be a window of time between when your program is started
and when it zaps its arguments. During that window, the arguments will be
available for all* to see.
I think you should re-evaluate your need to use command arguments.
* Mind you, systems, such as SCO Unix, which have C2 security, don't show
processes belonging to other users (unless you have the appropriate
permission). Not that I'm advocating a switch to C2 Unix.
David Newall, who no longer works Phone: +61 8 344 2008
for SA Institute of Technology E-mail: xt...@lux.sait.edu.au
"Life is uncertain: Eat dessert first"
Chris Lewis
>It is possible to give Oracle programs the username/password on the
>command line, ie :
> $ sqlplus scott/tiger
>This is all very nice, BUT when another user execute 'ps -ef' he/she
>can see the password!
>Is it possible to hide the arguments, so that they won't show up in
>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
I don't know how bullet proof this is, or how portable, but on many
versions of UNIX you can overwrite the character strings that the
argv[] array points to. Ie:
main(...) {
char *p;
/* parse arguments */
for (i = 0; i < argc; i++)
for (p = argv[i]; *p; p++)
*p++ = '\0';
You probably only have to zero the first byte in the argv[i] strings.
We used to do this to rename/hide executing game programs at a company I
used to work for. BTW: BSD 4.1 accounting wouldn't even show jobs that
had a control character in their name ;-)
This doesn't help directly, because you presumably don't have source
to sqlplus, and this only works for the *current* process.
What you could do is something like the above, but after clobbering
arguments, pipe/fork/exec sqlplus, and stuff the password down the
pipe, then relinquish stdin to the terminal. This, does still leave
a short window tho...
Frankly, if you're concerned about the password, you shouldn't do this
anyways - it becomes too tempting to put passwords in shell scripts...
--
Chris Lewis, Phone: (613) 832-0541, Internet: cle...@ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
Kartik Subbarao
>>>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
>
> This will ofcourse be a problem with sqlplus, but might work with
> 'runform' (using a user exit) or "home made" applications.
>
>My questions are now:
> Will 1 above work? Even if ps won't show the arguments, it might be possible
> to write a program which can read the argument list from memory. Is this
> possible? If it is, then this method isn't really safe.
No, the "ww" argument to ps will cause ps to not stop once it has reached
the max number of columns. You may want to pipe the output through fold.
Since only programs with access to /dev/kmem can get to where the argument
vector's stored, if ps didnt have such an option, the option of making a
big argv0 might be a viable solution. But, ps does have such an option.
> The problem with method 2 above is, as far as I can see, that it wouldn't
> be really safe because of race conditions. Ie. sometimes a user might have
> time to execute a PS in the time after the exec, and before the application
> have had time to destroy the argv structure. Is this correct?
Yes. This "problem" is documented in the man page for crypt(1). Crypt also
clobbers its argv array once it's read it in, but its possible to do a ps
just before it manages to do this and find it out.
-Kartik
--
internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'`
subb...@phoenix.Princeton.EDU -| Internet
kar...@silvertone.Princeton.EDU (NeXT mail)
SUBB...@PUCC.BITNET - Bitnet
Brandon S. Allbery KB8JRR/AA
+---------------
| >>Is it possible to hide the arguments, so that they won't show up in
| >>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
|
| I received a lot of replies for this question (Thanx to all!!), and the main
| result (until now) is that it isn't really possible (at least not in the
| general case).
|
| The best ones so far is:
| 1: exec the program with a very long argument ie.
| "<fullpath>//////////////////////////sqlplus scott/tiger"
|
| The idea of this is presumably, that ps only will show the first n
| characters of the argument list.
|
| 2: Modify the argv[] list in the exec'ed program after startup.
| This will ofcourse be a problem with sqlplus, but might work with
| 'runform' (using a user exit) or "home made" applications.
Not under Interactive or any other V.3 --- rather than having programs grunge
through process data space to find the arguments, the first PSARGSZ (80)
characters of the command line are written to u.u_psargs with '\0' changed to
a space. The first variant will work, though.
Yes, programs can chase your process VM to find the argv information... but
this requires root access (unless you have general read on /dev/mem and
/dev/swap, in which case you've got worse security problems than this to
contend with!).
++Brandon
--
Me: Brandon S. Allbery Ham: KB8JRR/AA on 2m, 220, 440, 1200
Internet: all...@NCoast.ORG (QRT on HF until local problems fixed)
America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88]
uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
Guy Harris
The problem with method 2 above is that, unless ISC UNIX is fairly
different from S5 as it comes from AT&T, "ps" doesn't *look* at the
argument list on the stack - it looks at the argument list as set up in
a string in the U area at startup, so your program can twiddle the argv
list until the cows come home and it won't affect what "ps" sees.
Guy Harris
>the max number of columns.
It will do so even in the ISC UNIX that the original poster said he was
using? News to me; the ISC UNIX in question is S5R3-flavored, and the
"ps" there may not even *have* a "ww" argument....
Brandon S. Allbery KB8JRR/AA
+---------------
...nor would it do any good, since running "ps" won't automagically increase
the size of the string stashed in the ublock.
Richard Todd
I must admit to not having great experience with "unadulterated" SysV, but
on two SysV-derived systems I've used (A/UX and ISC Unix), ps by default
only looks at the program name in the U area, but with the "f" flag will
go ahead and find the program's stack and read the arg. list. Also, by
default the U area "u_comm" field contains only argv[0] and none of the
other argv[i]. Example (on my home system, running A/UX 2.0):
---------------------------------------------------------------------------
9 servalan ~[5:46pm] % ps -p 358
PID TTY TIME COMMAND
358 console 0:07 xdm
10 servalan ~[5:46pm] % ps -fp 358
UID PID PPID C STIME TTY TIME COMMAND
root 358 129 0 15:34:03 console 0:07 /usr/bin/X11/xdm -nodaemon -udpPort 0
11 servalan ~[5:46pm] %
---------------------------------------------------------------------------
It works the same way on ISC Unix. I thought this was standard System V
behaviour. (I find it a tad unlikely that Apple and ISC would both add the
ability to read the stack arglist to ps, and do so with the exact same flag...)
--
Richard Todd rmt...@uokmax.ecn.uoknor.edu rmt...@chinet.chi.il.us
rmt...@servalan.uucp
"Elvis has left Bettendorf!"
Root Boy Jim
Around here, we run lots of sendmail, uucp, news, and a bit of ftp.
We like to know what's going on, so we use a function called
'setproctitle' (from the sendmail distribution). A bit of ps:
653 ? S N 10:14 -accepting smtp connections (sendmail)
5665 ? I 3:51 -timbuk.cray.com IHAVE (in.nntpd)
6175 ? I 0:01 -wuarchive.wustl.edu IHAVE (in.nntpd)
12017 ? S N 0:00 -mmmmmmm: SLAVE R (uucico)
12819 ? R N 0:00 -M2C.M2C.ORG: HELO m2c.m2c.org (sendmail)
13841 ? I N 0:03 -SSSSSSS-SSSSSS.ARMY.MIL:lskdfj: RETR ls-ltR.Z (in.ftpd)
14575 ? I N 0:01 -AA25083 finabo.abo.fi: greeting wait (sendmail)
15843 ? S N 0:11 -harpo.ssf-sys.DHL.COM:mbisted: RETR 1.39.tar.Z.18 (in.ftpd)
18014 ? I N 1:21 -AA22570 tohu0.weizmann.ac.il: user open (sendmail)
29152 ? S 4:00 -dddddd: MASTER SENDING (uucico)
We have a line in /etc/rc which says:
FILLER=" "; export FILLER
to give us some environment space to write over.
I certainly hope that future versions of UNIX will continue to provide
this information in the same fashion. At least provide a switch.
Don't tell me this is non-portable; it just happens to be the oldest way.
--
[rbj@uunet 1] stty sane
unknown mode: sane
Guy Harris
>the size of the string stashed in the ublock.
Well, no, it won't increase the size of the string stored there, but
that doesn't mean it wouldn't necessarily do any good; the reason for
"w" and "ww" in the BSD "ps" is that the BSD "ps" normally truncates the
entire line at 80 columns, by chopping the command off, and "w" and "ww"
increase the amount of command line printed.
A quick look at the S5R3.0 "ps" indicates that if the "-l" flag is
given, the string in the u area is chopped off at 35 characters rather
than PSARGSZ characters, so a "w" flag might be useful there as well.
Brandon S. Allbery KB8JRR/AA
+---------------
| I must admit to not having great experience with "unadulterated" SysV, but
| on two SysV-derived systems I've used (A/UX and ISC Unix), ps by default
| only looks at the program name in the U area, but with the "f" flag will
| go ahead and find the program's stack and read the arg. list. Also, by
A/UX is SVR2 internally; it reads argv[] out of the program's stack. ISC ---
which version? Try "grep u_psargs /usr/include/sys/user.h" and see if it
finds anything --- if it does, then you have a SVR3.[12] which copies the
first part of argv[] into the ublock.
++Brandon
--
Me: Brandon S. Allbery Ham: KB8JRR/AA on 10m,2m,220,440,1.2
Internet: all...@NCoast.ORG (restricted HF at present)
John 'tms' Navarra
I have been vaguely following this discussion and this might
sound simple (and of course it might not work) but if you want to hide a
process from ps (like a passwd call) how bout this:
make a /bin/ps which does the following:
exec /bin/psfiltered | grep -v passwd
then you hide psfiltered somewhere (maybe not in bin) but so it is not
readlily accessible by others and so everybody will call ps like usual but
now it can be supplied with a list not to display.
I don't know -- it's just off the top of my head.
--
From the Lab of the MaD ScIenTiST:
nav...@casbah.acns.nwu.edu
Kartik Subbarao
>
> I have been vaguely following this discussion and this might
> sound simple (and of course it might not work) but if you want to hide a
> process from ps (like a passwd call) how bout this:
>
> make a /bin/ps which does the following:
>
> exec /bin/psfiltered | grep -v passwd
Changing a system program is a really Stupid way of solving the problem.
First, the person that wants to do this is not necessarily the superuser,
or one with kmem access.
Secondly, it's really simple to have the program read the "secret"
arguments from the tty (maybe even using getpass!), rather than have to have
them passed as arguments.
Oh, gosh, that takes two more lines of code! I'll die from writing it!!
In any event, systems programs should not be changed on simple whims like
this. It's important that they be functional as they're expected to.
andre
>command line, ie :
> $ sqlplus scott/tiger
>This is all very nice, BUT when another user execute 'ps -ef' he/she
>can see the password!
>Is it possible to hide the arguments, so that they won't show up in
>the 'ps' output (possibly by 'exec'ing sqlplus in some devious way :-)??
Sure you can, try this for size:
main(argc, argv)
int argc;
char **argv;
{
char p[512];
if (argc == 2)
{
strcpy(p, argv[1]);
memset(argv[1], '\0', strlen(argv[1]));
sleep(30); /* time to check */
printf("argv[1] was %s \n",p);
}
return 0;
}
NOTE: untested code, but this explains the idea.
--
The mail| AAA DDDD It's not the kill, but the thrill of the chase.
demon...| AA AAvv vvDD DD Ketchup is a vegetable.
hits!.@&| AAAAAAAvv vvDD DD {nixbur|nixtor}!adalen.via
--more--| AAA AAAvvvDDDDDD Andre van Dalen, uunet!hp4nl!targon!andre
Scott Bennett
>In article <z91...@idunno.Princeton.EDU> subbarao@phoenix (Kartik Subbarao) writes:
>> [text deleted --SJB]
>>
>>Secondly, it's really simple to have the program read the "secret"
>>arguments from the tty (maybe even using getpass!), rather than have to have
>>them passed as arguments.
>
> terminals (which most systems don't now a days) how will you get the 'secret'
> argument?
[X-ray laser on]
Read what he said again. He mentioned nothing at all about other
users' terminals. He said the *program* should read from the tty instead
of looking at *argv[]. In other words, the morons who wrote the data
base program in question should have been roundly chastised by their
management. The product should never have been allowed out the door
in a form like that. The data base program should be fixed. There is
no need whatsoever to adulterate the operating system to fix a third-
party software vendor's bungling. The program should *also* turn off
the echo before reading the password. After all, it *is* a *password*
that the program is requiring.
[X-ray laser off]
>>
>>
>>In any event, systems programs should not be changed on simple whims like
>>this. It's important that they be functional as they're expected to.
Precisely.
>>
>> -Kartik
>
> [text deleted --SJB]
>>--
>>internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'`
>>
>>subb...@phoenix.Princeton.EDU -| Internet
>>kar...@silvertone.Princeton.EDU (NeXT mail)
>>SUBB...@PUCC.BITNET - Bitnet
>
>
>--
>From the Lab of the MaD ScIenTiST:
>
>nav...@casbah.acns.nwu.edu
Scott Bennett, Comm. ASMELG, CFIAG
Systems Programming
Northern Illinois University
DeKalb, Illinois 60115
**********************************************************************
* Internet: ben...@cs.niu.edu *
* BITNET: A01SJB1@NIU *
*--------------------------------------------------------------------*
* "Spent a little time on the mountain, Spent a little time on the *
* Hill, The things that went down you don't understand, But I *
* think in time you will." Oakland, 19 Feb. 1991, first time *
* since 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) *
**********************************************************************
John 'tms' Navarra
>>
>> I have been vaguely following this discussion and this might
>> sound simple (and of course it might not work) but if you want to hide a
>> process from ps (like a passwd call) how bout this:
>>
>> make a /bin/ps which does the following:
>>
>> exec /bin/psfiltered | grep -v passwd
>
>Changing a system program is a really Stupid way of solving the problem.
>First, the person that wants to do this is not necessarily the superuser,
>or one with kmem access.
I realize that the intent was not necc for someone without superuser
priveledges. That does not mean that there is not an interest in hiding
passwd calls if you have superuser privs.
>
>Secondly, it's really simple to have the program read the "secret"
>arguments from the tty (maybe even using getpass!), rather than have to have
>them passed as arguments.
Explain this one. If you don't have write access to other people's
terminals (which most systems don't now a days) how will you get the 'secret'
argument?
>
>
>In any event, systems programs should not be changed on simple whims like
>this. It's important that they be functional as they're expected to.
>
> -Kartik
I agree with you that perhaps you should not muck around with the system
programs. How bout a univeral alias that pipes grep -v passwd thru ps.
The whole point of this is not to advertise that it is being done, but rather
to stop people from trying to do 'timely' ps's.
>
>
>
>--
>internet# rm `df | tail +2 | awk '{ printf "%s/quotas\n",$6}'`
>
>subb...@phoenix.Princeton.EDU -| Internet
>kar...@silvertone.Princeton.EDU (NeXT mail)
>SUBB...@PUCC.BITNET - Bitnet
Kartik Subbarao
>>Changing a system program is a really Stupid way of solving the problem.
>>First, the person that wants to do this is not necessarily the superuser,
>>or one with kmem access.
>
>>arguments from the tty (maybe even using getpass!), rather than have to have
>>them passed as arguments.
>
> Explain this one. If you don't have write access to other people's
> terminals (which most systems don't now a days) how will you get the 'secret'
> argument?
What I mean is that, instead of accepting the password in an argument, the
program should use getpass() or something to prompt the user to type it in
after he runs the program. Clear?
>>In any event, systems programs should not be changed on simple whims like
>>this. It's important that they be functional as they're expected to.
>>
> I agree with you that perhaps you should not muck around with the system
> programs. How bout a univeral alias that pipes grep -v passwd thru ps.
> The whole point of this is not to advertise that it is being done, but rather
> to stop people from trying to do 'timely' ps's.
Gee, what if I have a program that's called "passwd", or some other
argument that is called "passwd", or whatever you plan to grep -v. This is
downright silly. An OS should not be made unpredictable in its behavior
because one user can't write a program that calls getpass() to get
sensitive information. It's really simple. Really it is.
-Kartik
Brandon S. Allbery KB8JRR/AA
+---------------
| A quick look at the S5R3.0 "ps" indicates that if the "-l" flag is
| given, the string in the u area is chopped off at 35 characters rather
| than PSARGSZ characters, so a "w" flag might be useful there as well.
3.0 is a bit old by now.
The current behavior is that ps only shows the short command name (u_comm)
unless the "-f" option is provided; then it prints out the entire u_psargs
string.
++Brandon
--
Me: Brandon S. Allbery Ham: KB8JRR/AA on 10m,2m,220,440,1.2
Internet: all...@NCoast.ORG (restricted HF at present)
Brandon S. Allbery KB8JRR/AA
+---------------
| of looking at *argv[]. In other words, the morons who wrote the data
| base program in question should have been roundly chastised by their
| management. The product should never have been allowed out the door
| in a form like that. The data base program should be fixed. There is
| no need whatsoever to adulterate the operating system to fix a third-
| party software vendor's bungling. The program should *also* turn off
| the echo before reading the password. After all, it *is* a *password*
| that the program is requiring.
The program (Oracle) was designed for IBM mainframes and block-mode terminals.
What else can you expect from such a losing origin?