Date: Tue, 27 Mar 2001 12:22:30 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Garance A Drosihn <drosih@rpi.edu> Cc: Kris Kennaway <kris@obsecurity.org>, Nate Williams <nate@yogotech.com>, "Michael A. Dickerson" <mikey@singingtree.com>, "Duwde (Fabio V. Dias)" <duwde@duwde.com.br>, freebsd-security@FreeBSD.ORG Subject: Re: SSHD revelaing too much information. Message-ID: <Pine.NEB.3.96L.1010327121329.81313P-100000@fledge.watson.org> In-Reply-To: <p05010404b6e5bb325d3c@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Mar 2001, Garance A Drosihn wrote: > One thing I was wondering is if the version information could be delayed > until the user has successfully authenticated to some user on the > destination host. Maybe any userid on the destination host, maybe just > some specific userid(s). I think that would give the version info out to > people who would have some RIGHT to know it, without leaving it out > there for absolutely anyone to anonymously discover. [this delay would > be an sshd configuration option, of course, so that administrators could > choose the behavior they wanted] Well, there are a couple of problems here: first, the banner is the first output from the server to the client (and, if I recall, in fact, the first stage in the protocol), meaning that there is no authentication that has taken place before. Second, the most likely failure source in the SSH protocol is during the complex negotiation stage, so if the information is to be available before the likely source of failure, it must be provided before the negotiation begins. > My next question is whether this version-paranoid behavior should key > off some system setting (a sysctl of some sort), as perhaps there are > other network-service daemons where this same issue comes up. Might as > well have them all key off a single option. Well, I would not be opposed to making global configuration of this type of release configurable, but would object to a sysctl being used to do so, as sysctl's are generally used to configure kernel parameters, not application parameters (with a few notable exceptions that are probably a mistake :-). A real-world limitation on the approach of a global parameter is that many of the larger chunks of application/protocol are maintained and distributed by third parties (sendmail, bind, ...) and that introducing global parameters introduces local modifications that may increase workload and merging tasks substantially. Also, there is not currently an abstraction for global management of per-application configurations, and introducing such a mechanism should probably done with a great deal of caution. It's unclear to me that the benefits of moving in this direction out-weight the costs, and that the benefits are even real for most consumers. An important first step would be to introduce the required run-time option into OpenSSH, and get that change accepted back by various maintainers of the software (OpenBSD, and the portable distribution). We already have a maintenance load problem due to increased divergence from the base distribution (introducing PAM, et al, into the OpenBSD distribution increases maintenance costs substantially), and we need to not make that problem worse, or risk creating larger problems than are solved through the new feature. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010327121329.81313P-100000>