mailing list archives
Re: Bug in SSH1 secure-RPC support can expose users' private keys
From: "Richard E. Silverman" <res () shore net>
Date: Sat, 20 Jan 2001 23:50:41 -0500
-----BEGIN PGP SIGNED MESSAGE-----
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.
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.
slade () shore net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: pgpenvelope 2.8.10 - http://pgpenvelope.sourceforge.net/
-----END PGP SIGNATURE-----