Re: Security Problems of using Pro-C

From: Kevin Neel <k-neel_at_nwu.edu>
Date: 17 Jan 1994 22:08:11 GMT
Message-ID: <2hf28b$3h5_at_anaxagoras.ils.nwu.edu>


Subject: Re: Security Problems of using Pro-C From: Ian Parkin, iparkin_at_lssec.bt.co.uk Date: 17 Jan 94 10:52:42 GMT
In article <1994Jan17.105241.5613_at_lssec.bt.co.uk> Ian Parkin, iparkin_at_lssec.bt.co.uk writes:
>>How safe is this: have the Pro*C application simply send "/" and use OS
>>authentication on the person running the program. That way, at least the
>>passwords aren't around for all to see. I'm sure there's some other
 problem,
>>but at least then it's at least as secure as the OS under it
 (hehehehe...).
>>Any experienced Oracle-dudes out there know the relative merits of this
 idea?
>
>As you said as secure as the OS itself. In the case of non-shadow Unix
 this means
>that your encrypted password is on public display and any number of
 programs are
>available to crack it.
>
>I guess it all depends on your level of paranoia whether you consider
 OPS$ accounts
>secure enough for your application or not.
>
>IAP
>

Seems to me that if you can
you can crack
an OS account, you can substitute your own frontends to (e.g.) Oracle tools and
squirrel away the passwords before invoking the real things.

I

On the other hand, on most UNIX systems, overwriting the password in your own C program is pretty easy -- just replace the characters in argv[0..argc] with spaces. Of course this does, as noted before, take a finite time after program startup, so looping ps(1) programs could possibly find the password beforehand.

How does your C program get started -- i.e. what program is passing the password?
Another C program? If so, there are many potential ways of passing stuff in. The environment was mentioned before (also works for shell scripts).  Pipes are another possibility (they need not use stdin if both programs are C).

If you want to use the environment, and you have a ps(1) that shows it, try creating a wrapper program that disables access to that option, and give it the privilege of running ps(1) -- a privilege that you don to regular users.

Note, often ps programs have a limit on how much they will show -- fill up the argument line or environment with extra spaces/variables and you can get around it. Received on Mon Jan 17 1994 - 23:08:11 CET

Original text of this message