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
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.
Current thread:
- Bug in SSH1 secure-RPC support can expose users' private keys ssh2-bugs (Jan 16)
- Re: Bug in SSH1 secure-RPC support can expose users' private keys c0n (Jan 17)
- Re: Bug in SSH1 secure-RPC support can expose users' private keys Andy Polyakov (Jan 18)
- Re: Bug in SSH1 secure-RPC support can expose users' private keys Richard E. Silverman (Jan 22)