Shell Programming and Scripting

Yes, I was referring to argv[] manipulation. Using memset() on argv[1]
* works with Linux 2.6.22 (OpenSuSE) using a non-suid ps, and with ps run as root
* does not work on HP-UX 11.31 using a non-suid ps
* does not work on FreeBSD 8.0 using a non-suid ps (as root)
* does not work on OpenSolaris 2009.06 using a non-suid ps

Seems like it's not dependent on the permissions of ps, but rather on the system.

Hey, pludi:

memset() on the string pointed to by argv[1] works on osx 10.4.11, where modifying the pointer in argv[1] directly (as my code was doing) failed.

Incidentally, as an unprivileged user, copying the suid ps binary so that it is no longer suid seems to work fine. I only tested a few options, however, so it's possible there's a privileged code path that I did not visit, just waiting to blow things up, but if collecting the process info did not require privilege -- I took a brief peek at Apple's ps.c, and it's using sysctl to gather the info; so, not surprising that privilige is not required for that step -- I don't see what would.

Regards,
Alister

Hi Corona, I think you got it wrong. I did mention that I knew authorized keys already (and I have been using it quite a while), but in my opinion it is not automation as expect (yes, I thought it wrong you may think), and that I did not hear of expect before.

Anyway, let us try not to diverge the main question of my post: how to fool ps or hide password in my script.

Thanks,

D.

---------- Post updated at 06:08 PM ---------- Previous update was at 06:02 PM ----------

Yes, I did. I tried it before combining my scripts to the script I posted. And the password still showed with ps.
I thought of this already, and it actually is a solution that a lot people recommend instead of passing password through arguments. But the permission of the file can be easily change by root, hence can be seen easily right?
And finally the decoded pass will be still passed to the argument of ssh or expect, or we can pass the encoded one?

Thanks,

D.

---------- Post updated at 06:14 PM ---------- Previous update was at 06:08 PM ----------

I found a post describing similar method, but I have no idea how to apply this to change (or fake) the name of the built-in process (such as expect or ssh) given its pid. If somehow ssh (or its argument) can be changed (or faked) then it is the solution, I think.

D.

---------- Post updated at 06:18 PM ---------- Previous update was at 06:14 PM ----------

Hi Alister,

I tried your code (modifying argv[1]) and it did not work on 10.6.3 either. Do you mean modifying memset() can change output of ps for built-in processes (xterm, expect, ssh, bash...) in my first post?

Thanks,

D.

In what manner is it worse do you think? It may not be easy to explain to your customers or superiors but it is fully automatic and secure. Your method is not and cannot be made secure. The inventor of ssh knew people would try to butcher in stored plaintext passswords anyway and designed it to prevent that. Not until you understand that the reason you have to use expect at all is because you're brute-forcing an insecure solution ssh was expressly designed to not just prevent but make obsolete.

I meant that the following works on 10.4.11, for clearing out all argument strings pointed to from argv (which usually show up in ps output):

Code:

#include <string.h>
#include <unistd.h>

int
main(int argc, char **argv) {
    while (--argc) {
        memset(argv[argc], 0, strlen(argv[argc]));
    }
    sleep(30u);
    return 0;
}

You cannot do this from a shell script, though. Also, even if you could, there is a race condition present. The args could be visible from ps if ps is run at just the right time and the kernel's process scheduler conspires against you.

As Corona has made clear, there is no secure way to accomplish what you're trying to do. The best you can manage is a few obstacles to keep the undetermined at bay.

Regards,
Alister

Got it. Thanks Alister.

D.

One other point - this kind of thing is such a common question that you may as well be directed to a FAQ about UNIX passwords:
Unix Programming Frequently Asked Questions - 4. System Information You want section 4.2 Passwords

... to make your life easier consider reading all of the FAQ pages.