[18719] in bugtraq
Re: Bug in SSH1 secure-RPC support can expose users' private keys
daemon@ATHENA.MIT.EDU (Richard E. Silverman)
Mon Jan 22 17:39:40 2001
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.10101202330250.1201-100000@syrinx.oankali.net>
Date: Sat, 20 Jan 2001 23:50:41 -0500
Reply-To: "Richard E. Silverman" <slade@shore.net>
From: "Richard E. Silverman" <res@shore.net>
X-To: Andy Polyakov <appro@fy.chalmers.se>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <3A673406.8C0C6EDD@fy.chalmers.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 18 Jan 2001, Andy Polyakov wrote:
> In my environment I can *never* see key_encryptsession returning the
> success value in the lack of my secret key and I get "run keylogin" all
> the time... So that it must be something specific to Richard Silver-man's
> NIS+ (mis?)configuration... And indeed, it appears that if
> /etc/nsswitch.conf is configured with "publickey: nisplus files" keyserv
> falls down to nobody's key-pair found in /etc/publickey and uses that
> private key whenever user private key is not around.
This appears to in fact be what's going on. I wrote:
res> ... most of the time, key_encryptsession returns success instead, and
res> appears to have encrypted its argument only with the public key of
res> the target netname, simply skipping the other encryption step. This
res> produces a magic phrase which can be generated easily by any other
res> user on the system.
I said "appears" because I wasn't sure exactly what was going on. The end
result was a key that could be produced by any user without access to my
RPC private key, so I made a guess that the common, public element was my
RPC public key alone. I wasn't aware of the "feature" of falling back to
using nobody's credentials.
I have confirmed that either running "keyserv -d", or deleting nobody's
secure-RPC keys, makes the bug go away. So it seems clear that the real
mechanism at work is the fallback to using "nobody"'s secure-RPC keys, to
which all users have effective access.
I assume the reason Andy could not replicate the effect, is that he was
using NIS+. My test cases used the /etc/publickey file alone -- perhaps
the "nobody fallback" does not work with (certain configurations of?) NIS+
due to table permissions.
> > FIX:
>
> I should recommend to configure NIS+ properly instead...
While I agree that it would be better to disable the fallback-to-nobody
feature when configuring secure-RPC, I do not agree with recommending this
"instead" of applying the fix I suggested. There's no reason to leave a
serious vulnerability in SSH1 which is triggered by an easy and common
host OS configuration. The fix is simple and prevents the problem,
regardless of how secure-RPC has been configured.
- --
Richard Silverman
slade@shore.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.8.10 - http://pgpenvelope.sourceforge.net/
iD8DBQE6amqmRF4zsgDn/HcRAjt9AKC9aITLFgso7dE1CbYNZ6jUfA++AACeJ1me
hl6v6eMXN/ZR+GcGWo32J3s=
=yZpu
-----END PGP SIGNATURE-----
