Re: Bug in SSH1 secure-RPC support can expose users' private keys

["Richard E. Silverman" <res () shore net>]

-----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-----