Bugtraq mailing list archives
Re: sshd1 allows unencrypted sessions regardless of server policy
From: mhw () WITTSEND COM (Michael H. Warfield)
Date: Tue, 14 Dec 1999 14:35:05 -0500
One nit in what was a good analysis over-all... On Tue, Dec 14, 1999 at 04:43:32PM +0100, Markus Friedl wrote:
[I am posting this here since nobody seems to take care of ssh-1.2.27]
I would like to bite on that line, but I think I'll be a good boy today... [...]
Because passphrase-less hostkeys are 'encrypted' with cipher "none" the code for this cipher is always compiled into the programs. This way the client is free to choose "none" and no server will complain.
AFAIK... The passpharse-less host keys are encrypted with 3-DES and no password. They were, at one time, encrypted with IDEA with no password. This is according to the documentation (specifically some remarks Tatu made in the Changes file). As you discovered with this hole, reality may differ from documentation space. I know about this because I ran smack into a compatibility problem upgrading a number of my older hosts to use OpenSSH. If the host key was generated with an old enough version of SSH (around 1.2.8 or so), the host key was encrypted with IDEA, which OpenSSH does not support. That meant that just after upgrading to OpenSSH, you're toast because the daemon can not read the host key (error is "unsupported encryption algorithm"). The solution is to run "ssh-keygen -u /etc/ssh_host_key" (modify for your host key location), using the ssh-keygen program from ssh-1.2.27, prior to the ugrade (the OpenSSH keygen program can't read the old key either and doesn't support the -u option). According to the ssh docs, that re-encrypts the host key in the default algorithm (3-DES in the case of 1.2.27). No harm is done by running "ssh-keygen -u" on a newer key. So... You say the host key is not encrypted. The documentation says that it's encrypted 3-DES with no passphrase. I know that older host keys were encrypted with an algorithm which OpenSSH can not read (and identifies it by number as IDEA). I also know that running ssh-keygen on the host key corrects the incompatibility. It could be that the new host key is encrypted with 3-DES and no password as stated in the docs or it could be that it's encrypted with NONE. Both would account for the behavior I've seen. Since you've already discovered one discrepancy, a second one is not that unlikely... Like I said... Just a nit... Mike -- Michael H. Warfield | (770) 985-6132 | mhw () WittsEnd com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Current thread:
- Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability, (continued)
- Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Ussr Labs (Dec 13)
- Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Malartre (Dec 14)
- Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Ussr Labs (Dec 14)
- Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Federico - Comnet S.A. (Dec 15)
- Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70Vulnerability ussr secure (Dec 16)
- Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Tim (Dec 15)
- Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Ussr Labs (Dec 15)
- Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Ussr Labs (Dec 13)
- CERT Advisory CA-99-16 Buffer Overflow in Sun Solstice AdminSuite Daemon sadmind Elias Levy (Dec 14)
- Statement: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Jarle Aase (Dec 16)
- Re: sshd1 allows unencrypted sessions regardless of server policy Michael H. Warfield (Dec 14)
- Re: sshd1 allows unencrypted sessions regardless of server policy Pavel Machek (Dec 14)
- Re: sshd1 allows unencrypted sessions regardless of server policy Joseph Moran (Dec 14)
- Re: sshd1 allows unencrypted sessions regardless of server policy David Schwartz (Dec 15)