Re: SSHD revelaing too much information.

From: Robert Watson (
Date: 03/27/01

Date: Mon, 26 Mar 2001 22:33:41 -0500 (EST)
From: Robert Watson <>

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

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 NAI Labs, Safeport Network Services

To Unsubscribe: send mail to
with "unsubscribe freebsd-security" in the body of the message