75672 2002-09-17 18:54 /26 rader/ Andrew Danforth <acd@weirdness.net>
Importerad: 2002-09-17 18:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1524>
Ärende: OpenSSH 3.4p1 Privsep
------------------------------------------------------------
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
(75672) /Andrew Danforth <acd@weirdness.net>/(Ombruten)
75807 2002-09-18 21:45 /14 rader/ <eric@catastrophe.net>
Importerad: 2002-09-18 21:45 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1571>
Ärende: Re: OpenSSH 3.4p1 Privsep
------------------------------------------------------------
On Mon, 2002-09-16 at 17:48:42 -0400, Andrew Danforth wrote...
; 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.
This appears to not happen on FreeBSD using the OpenSSH 3.4p1 source
(not the FreeBSD distro). Also, it doesn't happen when using pub/priv
key authentication, as far as I can tell.
-#0
(75807) / <eric@catastrophe.net>/-------------------
75822 2002-09-19 01:56 /62 rader/ Peter J. Holzer <hjp@wsr.ac.at>
Importerad: 2002-09-19 01:56 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1579>
Ärende: Re: OpenSSH 3.4p1 Privsep
------------------------------------------------------------
On 2002-09-16 17:48:42 -0400, Andrew Danforth wrote:
> 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.
Similar techniques work even without privilege separation, although
they may not not be so widely known or available.
For example, on Linux there is a utility "ltrace", which traces
library calls. And sure, enough, I find the password I typed (which
is not my real password, of course) in a call to memcpy:
| strcmp("hjp", "hjp") = 0
| strcmp("ssh-connection", "ssh-connection") = 0
| strcmp("password", "publickey") = -20
| strcmp("password", "password") = 0
| memcpy(0xbffff4b7, "", 1) = 0xbffff4b7
| memcpy(0xbffff454, "", 4) = 0xbffff454
| malloc(4) = 0x0808fe90
| memcpy(0x0808fe90, "foo", 3) = 0x0808fe90
^^^ here it is.
| pam_set_item(0x080984f0, 5, 0x08086118, 0x08096e20, 0x08096e20) = 0
| pam_authenticate(0x080984f0, 1, 0x08086118, 0x08096e20, 0x08096e20
| <unfinished ...>
This is on a Redhat Linux 7.3 box with OpenSSH 3.1p1.
> 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.
An unencrypted shadow password file would immediately disclose all
passwords to the intruder. By sniffing passwords, the intruder only
gets the passwords of the people who logged in using passwords during
the time until he is discovered. Depending on the use of the system,
this may make a difference. Also, password files are traditionally
encrypted on Unix. Why should OpenBSD change that, even if it doesn't
add much security?
> The level of effort to determine cleartext passwords, for even the most
> inexperienced Unix administrator, is almost zero given the above. I
If you don't trust the sysadmin, don't put anything secret on his
computer. You should be concerned about people who get root
privileges illegitemately, however. Any script kiddie who is able to
download some l33t r00t exploiz is probably also able to find a
trojaned sshd somewhere. I'm less sure if they know about strace,
though :-)
hp
--
_ | Peter J. Holzer | Aeltere Sources (also solche, die schon
|_|_) | Sysadmin WSR / LUGA | aelter als 12 Stunden sind) sollte man
| | | hjp@wsr.ac.at | bei Linux generell nicht einsetzen -
__/ | http://www.hjp.at/ | Real Time Linux?? -- Gerhard Schneider
(75822) /Peter J. Holzer <hjp@wsr.ac.at>/-(Ombruten)
Bilaga (application/pgp-signature) i text 75823
75823 2002-09-19 01:56 /12 rader/ Peter J. Holzer <hjp@wsr.ac.at>
Importerad: 2002-09-19 01:56 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1580>
Bilaga (text/plain) till text 75822
Ärende: Bilaga till: Re: OpenSSH 3.4p1 Privsep
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iQDPAwUBPYdvv1LjemazOuKpAQGPNAXQ0R/ak9+52PLE22fqInh1vrDDQHMACVJS
+v61V+O/VAP2idNBGKXGMfr9KFuY7XVGtwEzqlULKFl7+/7meOh8qgzy5hhOuJug
nstoA1MWz9Az9XN0Y1OWan4H+QF0L3IyAxUSC2fC7DcKswsvDwPaEfFcZvMYJfa2
4hZ5ixaXljFFnoq7OLVwZL7i64aWgrGIfDIZjvZNKjleRnaXOHBenFRJmieIghQ8
2AkMimN/BKTdXErinnPySPmE
=eYfo
-----END PGP SIGNATURE-----
(75823) /Peter J. Holzer <hjp@wsr.ac.at>/-----------
75833 2002-09-19 07:56 /47 rader/ Just Marc <marc@corky.net>
Importerad: 2002-09-19 07:56 av Brevbäraren
Extern mottagare: Andrew Danforth <acd@weirdness.net>
Mottagare: Bugtraq (import) <1590>
Ärende: Re: OpenSSH 3.4p1 Privsep
------------------------------------------------------------
| 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
/ \
(75833) /Just Marc <marc@corky.net>/----------------
75839 2002-09-19 09:01 /33 rader/ Artem Chuprina <bugtraq@ran.pp.ru>
Importerad: 2002-09-19 09:01 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <1593>
Ärende: Re: OpenSSH 3.4p1 Privsep
------------------------------------------------------------
On 2002.09.16 at 17:48:42 -0400, Andrew Danforth wrote:
> 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.
Because these passwords are stored. That is, if /etc/shadow is
stealed by malicious user because of administrator's mistake, it is a
challenge for that user to get passwords from their encrypted
state. This is not an issue for temporary objects, that's why pipes
are considered secure.
> 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`
It is also trivial to read process' memory and so on.
--
Artem Chuprina <ran@ran.pp.ru>
FIDO: 2:5020/122.256
(75839) /Artem Chuprina <bugtraq@ran.pp.ru>/(Ombruten)