CODEWITHSUNDEEP
linuxbashcommand-linecommand-line-argumentspassword-protection
David Parks
David Parks

Reputation: 32081

Shell script password security of command-line parameters

If I use a password as a command-line parameter it's public on the system using ps.

But if I'm in a bash shell script and I do something like:

...
{ somecommand -p mypassword }
...

is this still going to show up in the process list? Or is this safe?

Upvotes: 7

Views: 13254

Answers (4)

puja
puja

Reputation: 51

How about using a file descriptor approach:

env -i bash --norc   # clean up environment
set +o history
read -s -p "Enter your password: " passwd
exec 3<<<"$passwd"
mycommand <&3  # cat /dev/stdin in mycommand

See:

Hiding secret from command line parameter on Unix

Upvotes: 5

Maxim Razin
Maxim Razin

Reputation: 9466

The called program can change its command line by simply overwriting argv like this:

#include <stdlib.h>
#include <string.h>

int main(int argc, char** argv) {
    int arglen = argv[argc-1]+strlen(argv[argc-1])+1 - argv[0];
    memset(argv[0], arglen, 0);
    strncpy(argv[0], "secret-program", arglen-1);
    sleep(100);
}

Testing:

$ ./a.out mySuperPassword & 
$ ps -f
UID        PID  PPID  C STIME TTY          TIME CMD
me       20398 18872  0 11:26 pts/3    00:00:00 bash
me       20633 20398  0 11:34 pts/3    00:00:00 secret-program
me       20645 20398  0 11:34 pts/3    00:00:00 ps -f
$

UPD: I know, it is not completely secure and may cause race conditions, but many programs that accept password from command line do this trick.

Upvotes: 3

Kilian Foth
Kilian Foth

Reputation: 14346

The only way to escape from being shown in the the process list is if you reimplement the entire functionality of the program you want to call in pure Bash functions. Function calls are not seperate processes. Usually this is not feasible, though.

Upvotes: 0

sehe
sehe

Reputation: 393104

Command lines will always be visible (if only through /proc).

So the only real solution is: don't. You might supply it on stdin, or a dedicated fd:

./my_secured_process some parameters 3<<< "b@dP2ssword"

with a script like (simplicity first)

#!/bin/bash
cat 0<&3

(this sample would just dump a bad password to stdout)

Now all you need to be concerned with is:

  • MITM (spoofed scripts that eaves drop the password, e.g. by subverting PATH)
  • bash history retaining your password in the commandline (look at HISTIGNORE for bash, e.g.)
  • the security of the script that contains the password redirection
  • security of the tty's used; keyloggers; ... as you can see, we have now descended into 'general security principles'

Upvotes: 9

Related Questions