|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <Pine.BSF.4.10.9912150058510.498-100000@gwydion.null> Date: Wed, 15 Dec 1999 01:06:24 -0500 Reply-To: Joseph Moran <jmoran@IPASS.NET> From: Joseph Moran <jmoran@IPASS.NET> X-To: BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM In-Reply-To: <19991214220021.C153@bug.ucw.cz> On Tue, 14 Dec 1999, Pavel Machek wrote: > > 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. > > And what? Malicious ssh client can make non-encrypted connection. But > malicious ssh client can also send carbon-copy of all communication to > www.cia.org:5000! There's no way to protect from malicious ssh > clients... Of course, but that's no excuse for a lapse in good programming. If the server tells the client "here, pick from this list", it's common sense that the server would check the client's response to see if it's valid. That aside, this hole could be useful in a situation where Party A wants to help Party B compromise a system without leaving a paper trail. Party A trojans an ssh client binary, Innocent Bystander C does an ssh connection somewhere, and Party B sniffs the cleartext traffic. No evidence to point to Party B. If instead Party A trojaned the binary to send Party B a carbon-copy, and a white hat could extract this, then Party B is implicated. jm
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |