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

[Andy Polyakov <appro () FY CHALMERS SE>]

Hello,

> There is a bug in SSH-1.2.30 involving Secure RPC. The patch for this is
> available at http://www.ssh.com/patches.html.
>
> The explanation and bug was submitted by Richard Silverman
> (slade () shore net), and his explanation of the bug is below. The SSH1
> protocol is not formally supported by SSH Communications Security.
> However, as a service to the user community, we offer this patch as a
> potential way of addressing SSH1 related issues.

It probably should be noted that the "offending" code is present even in
SSH 2.x, but it never gets invoked during the key generation process
(i.e. in SSH 2.x). I write "offending" in quotes because I can't confirm
following statement no matter how many times I try:

> The problem occurs if I encrypt an SSH key using the SUN-DES-1 magic
> phrase, without having done a keylogin -- that is, keyserv does not have
> my Diffie-Hellman private key. ... most of the time,
> key_encryptsession returns success instead, and appears to have encrypted
> its argument only with the public key of the target netname, simply
> skipping the other encryption step.

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 Silverman'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. It's discussible if
"publickey: nisplus files" is "the right thing," but the facts are:

- by default it contains "publickey: nisplus" alone;
- nobody's key-pair found in /etc/publickey is well known (it's
disseminated through OS distribution media, i.e. it's not generated
during installation and it has the same value on all computers and all
OS releases), it's not good idea to involve it;
- use for nobody's key-pair is not documented anywhere and I have it
hard to imagine what it would be useful for;
- keyserv offers -d command line option disabling the use of default
keys for nobody;

> FIX:

I should recommend to configure NIS+ properly instead (having well known
key involved in authentication may have undesirable effect) or start
keyserv with -d flag. If you seek a simpler way (i.e. simpler than
restarting keyserv on every workstation) to instantly "revoke" the magic
phrases encrypted with nobody's key, delete (or rename) /etc/publickey
on every workstation.

Andy.