8

This is loosely related to one of my recent answers. I've listed 4 methods of adding a new user via mkpasswd and useradd combination on Ubuntu 16.04.

  1. Command substitution:

    sudo -p ">" useradd -m -s /bin/bash -p $(mkpasswd --hash=SHA-512 "123" ) newusr

  2. Single quoting:

    sudo -p ">" useradd -m -s /bin/sh -p 'GVhvDY$vhw89D2X0bd2REQWE' newusr2

  3. Passing via pipe to xargs:

    mkpasswd -m sha-512 'password1' | sudo -p '>' xargs -I % useradd -p % newuser1

  4. Appending backslashes to each $

    useradd -m -s /bin/bash -p \$6\$5AfGzrQ9u\$r6Q7Vt6h8f2rr4TuW4ZA22m6/eoQh9ciwUuMDtVBX31tR3Tb0o9EB1eBdZ2L9mvT.pX3dIEfxipMoQ0LtTR3V1 newuser

In case of method 4 and 2, it's clear that hashed password appears in the process list; this is not entirely secure. However, I'm curious about methods 3 and 1. Do command substitution and piping prevent a malicious user from somehow obtaining the hashed password ? Can malicious user somehow read stdout or stdin of either command ?

Sergiy Kolodyazhnyy
  • 519
  • 5
  • 17
  • 1
    Command substitution passes the value _to the shell_ safely but then the shell passes to useradd exactly the same as an explicit argument and it is exposed exactly the same. Piping by itself is safe, but piping _to xargs_ passes the argument to useradd exactly the same as an explicit argument and it is exposed exactly the same. In short, **if it's an argument, it's an argument**, and arguments are exposed -- unless you mount /proc with HIDEPID. – dave_thompson_085 Dec 04 '17 at 05:19
  • 3
    @dave_thompson_085 can you make that an answer and explain in detail, maybe with a few examples ? – Sergiy Kolodyazhnyy Dec 04 '17 at 05:42
  • 1
    The hashed password in the argv of useradd is nowhere near as bad as the plain password in the argv of mkpasswd. –  Dec 04 '17 at 14:45
  • A lot depends on what privileges the malicious user has on the system (e.g. access prior/during/after password use, account with other/same/root user, shell rather than file/device access etc.) – Enos D'Andrea Mar 19 '18 at 07:01

1 Answers1

1

While the approach may have some advantages, there are several ways the password still may be intercepted.

The bash history will show the password in plaintext, the makepasswd command may be compromised, the shell may be compromised and so on. There is little reason to do this honestly. Generally, what an attacker can do depends a lot on his privileges, but I would not consider either of these approaches more/less secure. As far as I can tell, 1 and 3 are about the same in terms of security. A pipe may seem better, as it bypasses shell, but shell already has the plain-text password, so there is really no reason to worry about that. Still, I would probably go with the pipe.

PS: Both of these may still show plain-text password in the process list while makepasswd is running.

Peter Harmann
  • 7,728
  • 5
  • 20
  • 28