Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Bug in SSH1 secure-RPC support can expose users' private keys
From: Andy Polyakov <appro () FY CHALMERS SE>
Date: Thu, 18 Jan 2001 19:20:54 +0100


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;


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.


  By Date           By Thread  

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