Home page logo
/

bugtraq logo Bugtraq 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-----
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-----


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault