| During authentication, OpenSSH 3.4p1 with privsep enabled passes the
| cleartext password from the main process to the privsep child using a
| pipe. Using strace or truss, root can see the user's plaintext password
| flying by. I observed this behavior from OpenSSH 3.4p1 built using GCC on
| Solaris 2.8 and the current Debian OpenSSH 3.4p1 package.
|
| Theo and Markus tell me that this is not an issue. Theo says that you
| cannot prevent root from determining a user's password. I don't disagree,
| but asked why OpenBSD bothers to encrypt user passwords at all if that is
| his attitude.
|
| The level of effort to determine cleartext passwords, for even the most
| inexperienced Unix administrator, is almost zero given the above. I
| realize that no matter how you slice it, it will be possible for root to
| grab the password from wherever it's stored in memory. Or recompile sshd
| to log the password, or any number of other ways. However, the methods I
| just mentioned all require someone with significantly more know how than:
|
| truss -fp `cat /var/run/sshd.pid`
|
| I'm not saying this is a bug, rather I thought it worthwhile to share with
| the community and let you all come to your own conclusions.
Andrew, this has been possible with normal openssh, ssh.com and
various different software that does password authentication.
Simply launch ltrace and one of the standard library calls should be
used to copy or compare passwords or critical pieces of data such as
keys. For example, in OpenSSH you could observe this behavior by
ltracing and watching the library function memcpy copy the cleartext
password by ...
So this is nothing new.
bye,
Marc.
--
marc @ corky.net
fingerprint = D1F0 5689 967F B87A 98EB C64D 256A D6BF 80DE 6D3C
/"\
\ / ASCII Ribbon Campaign
X Against HTML Mail
/ \
