Date: Mon, 26 Mar 2001 22:33:41 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: freebsd-security@freebsd.org Subject: Re: SSHD revelaing too much information. Message-ID: <Pine.NEB.3.96L.1010326222811.81313F-100000@fledge.watson.org> In-Reply-To: <20010326213930.B15891@pir.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Mar 2001, Peter Radcliffe wrote: > Robert Watson <rwatson@FreeBSD.ORG> probably said: > > Note that BIND used to require recompiling its version string, but > > now allows it to be changed using run-time parameters. > > For as long as I can remember (read; as long as I've been doing it) > you've been able to block BIND from giving out it's version number > without recompiling by creating a chaos/bind zone and adding a query > acl. "changed" != "blocked". These are different situations: in SSH, the server must offer a version string to the client, to allow negotiation of protocol parameters supported by both sides of the connection. Then the question becomes, what optional implementation string do you stick in: blocking the query is not possible in the same style as a DNS query (you cannot return a discernable "error" to the client, you can merely modify the field, possibly ommitting useful information). In my example, originally the text in question was compile-time determined, but later this changed. In fact, even until recently, there were still compile-time constants that could be returned in the CHAOS namespace that could not be modified. However, even once you've blocked the ability to request the specific revision of BIND, it's trivial to use a range of queries to "fingerprint" the version of the server by both attempting to use features supported by only some BIND versions, and by attempting to trigger bugs present only in specific versions or version ranges. The fundamental issue here is that version numbers *reflect* behavioral changes, meaning that what the attacker really cares about is the behavior, not the version number, for the purposes of exploiting a bug. Having the precise version number allows, as I've indicated, tailoring of the attack path, but it isn't required to successfully exploit a security hole. 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.1010326222811.81313F-100000>