Shell Programming and Scripting

There's no "best" way. They all suffer from exactly the same problem: Anyone who can see the code will know how to crack your password, and they'll have unlimited tries to guess your obfuscation. You might have noticed that you already had to brute-force your way around ssh's security features with 'expect' to do what you want; that's a subtle hint, in mile-high neon letters You're really not supposed to do that. It's really not a good idea. If you can pre-share a password, why can't you pre-share a key?

That is so true Corona, and I should have quoted "Best" to imply what I really wanted when posting the question: I want to learn. Few days ago I still thought that ssh was impossible to be automated, and then I learned about expect. Now I want to learn a way (if there is one) to fool ps .

Automated ssh without my presence using my account is already not allowed if strictly considering the account policy, and of course I am not allowed to share my password. But it is really a matter of knowledge that I like the solution so much so that I want to learn more... Everything is still in development, and that I have them all in my control.

D.

Hi:

You are not going to fool ps. ps gets its process data from the kernel. You'd have to modify the kernel to lie/obfuscate, then recompile it. Or, you'd have to modify and recompile ps to lie/hide/obfuscate. And, you can forget about any LD_PRELOAD tricks since ps is a SUID binary.

Regards,
Alister

Wrong. Any C program can lie to ps and the kernel, simply by changing it's arguments. The only restriction is that the new contents may not be larger than the original if you just overwrite it (example available on request). But with just shell scripting, no, it's not possible.
Wrong. Any binary may query the kernel about running processes. On HP-UX:

Code:

$ ll `which ps`
-r-xr-xr-x   1 bin        sys         147264 Dec 17  2008 /usr/bin/ps

On Linux:

Code:

> ll `which ps`
-r-xr-xr-x 1 root root 105280 21. Sep 2007  /bin/ps

Have you tried the following:

1. Put the script in a separate expect script file, and use your bash script as a wrapper script. From bash, call the expect file. This will prevent the expect commands from appearing in ps.

2. Instead of hardcoding the password in the file, store the password in a separate file and protect the file so that only the authorised users can access it.

3. Instead of using a password, encode the password algorithm instead. For example your password may be month-based, e.g. mypasswdJul2010, so put the algorithm in the code to generate it.

expect is an ugly, last-resort solution for things that won't cooperate any other way, and tends to make insecure and unreliable solutions. If you think ssh can't be automated without it, you've learned the wrong lesson; there's a much better and more secure method built into ssh itself: authorized keys. It doesn't make much sense to say "my account policy says I can't automate this; therefore I'll automate it anyway, avoid the proper way since that's not allowed, and use the least secure and most contrived way imaginable instead!" Somehow I don't think that's what their security policy had in mind.

Hi, pludi:

From the original post: It wasn't my intention to assert that every ps implementation is suid, just those that are of interest to the original poster.

From OSX 10.4.11:

Code:

$ ls -l $(which ps)
-rwsr-xr-x   1 root  wheel  68432 Dec  7  2006 /bin/ps

From (a friend's) OSX 10.5.8:

Code:

$ ls -l $(which ps)
-rwsr-xr-x 1 root wheel 85536 Sep 10 2008 /bin/ps

I assume you mean modifying argv[]. Testing with the following code that I whipped up:

Code:

#include <unistd.h>

int
main(int argc, char **argv) {
    argv[1]="fake";
    sleep(30u);
    return 0;    
}

In the discussion that follows, success means that after invoking the executable with "./a.out real", ps lists it as "./a.out fake".

FAILURE: OSX 10.4.11 (suid ps)
FAILURE: Debian (kernel 2.6.18-5-686, non-suid ps)
SUCCESS: OpenBSD 4.4 (non-suid ps).

(Yeah, I have a lot of old machines lying around with outdated os installs )

Furthermore, in the BSD-ish cases (at least, perhaps others), the struct with the process info contains the original argv in addition to the current argv (which may differ as when deliberately modified by the process itself).

If you were referring to a different type of argv manipulation, or something altogether different, or if there's an error in my C code, I would appreciate the enlightenment.

Regards,
Alister