Date: Mon, 26 Mar 2001 21:30:55 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Kris Kennaway <kris@obsecurity.org> Cc: 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.1010326205118.81313D-100000@fledge.watson.org> In-Reply-To: <20010326133953.E7234@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
OK, so I go knowingly into a heated discussion :-). I think that a number of reasonable arguments have been made on all sides, so let me walk you through my reasoning to reach the conclusion that I reached: 1) An important class of attackers can substantially benefit from increased information concerning the specific version of software in use. While it is true that there is a common class of attacker that does not probe the object of the attack for version information (those using a number of broadly-targetted "sweep" attack engines), there is another imporant class of attackers that will benefit from this information: attackers specifically targetting your host. In such a scenario, it is very important to carefully identify and exploit the vulnerability, because failed attempts (due to mis-characterization of the victim operating system software, hardware architecture, or application software) are easy to detect and commonly logged. Being able to select the exploit to specifically take advantage of the vulnerability present without failed attempts is important to a well-crafted attack. As such, having specific version information exposed in the protocol banner can facilitate attacks in a concrete manner. This seems to jibe well with the argument made that this is not "security by obscurity", but rather a strategic decision that has a practical impact on the effectiveness of the most deadly class of attackers: the informed adversary. Even if you are vulnerable to a specific vulnerability, forcing the attacker to attempt to exploit it (perhaps unsuccessfully) can be important in revealing the presence of the attacker, and limiting the scope of their undetected capabilities. 2) Several important classes of software consumers benefit from the explicit detailing of version information. A number of consumers of this banner information are present, and they represent an important class of users. Just off the top of my head, I can identify at least two reasons why revealing version information is useful: First, it allows mass-detection of vulnerable hosts without more complicated (or dangerous) detection mechanisms. Even on the scale of a small number of hosts, being able to take advantage of this technique is very important to many installations. In fact, when the recent BIND vulnerability was announced, a number of efforts were made to sweep the Internet to detect vulnerable nameservers, and notify the administrators of the problem. A number of commercial vulnerability scanning tools, as well as freely available tools (including one tool released by the OpenSSH development team) can use this banner information to generate suspected vulnerability lists. In fact, there are even ASP services available that will scan the connecting host for vulnerabilities in return for a moderate fee, and the only "safe" way to do this (i.e., without exploiting the bug itself) is via version headers. Second, version information can be extremely useful in diagnosing connection and protocol negotiation failures, especially when the debugging scenario is unilateral (for whatever reason). Minor protocol incompatibilities or obscure authentication negotiation bugs can be almost impossible to diagnose without detailed version information. 3) This information is already revealed by all known releases of OpenSSH: despite the claim, nothing has "changed". The objection to this change was raised when it was determined that we now revealed information about the precise version of the software executing on the host. I object that in fact, this information has always been available, modulo local patches. If you track the standard OpenSSH distribution, it reveals the version number you installed on your system. And in practice, most consumers of OpenSSH either use the released OpenSSH version, or the precise version of OpenSSH that shipped with their operating system. For example, the following banners are ones I peeled out of connections to a number of existing systems, demonstrating that this facility to detect remote version numbers is not "new" or a recent change in policy: SSH-1.5-OpenSSH-1.2.1 SSH-1.99-OpenSSH_2.3.0 SSH-1.5-1.2.27 All that has happened is that Brian has differentiated our version from the OpenSSH released versions. 4) There is strong precedent for the revealing of version information in protocol headers by default. 220 censored. ESMTP Sendmail 8.11.1/8.11.1; Mon, 26 Mar 2001 21:07:07 -0500 (EST) 220 censored. FTP server (Version 6.00LS) ready. Server: Apache/1.3.9 (Unix) And you really don't want to see the output of telnet option negotiation :-). Part of this reporting of version information is really a function of negotiating optional components of a service, or extensions. For example, using SSH without exposed version information, I can probe the set of available authentication services, as well as available crypto algorithms, which can let me substantially narrow down the range of available versions you could be using. Due to changes in negotiation procedures, protocol version number, and *even susceptibility to certain security (and other) bugs*, it is very hard to hide this information. 5) A compromise solution is appropriate that takes into account all of these (and other) considerations. I think the proponents of revision information hiding have made a strong case that in their environments, the ability to hide version information is an important component of their security stance. They have successfully argued that making the exposure of this information a compile-time option presents a substantial challenge to their ability to realize this stance. However, I think they have failed to successfully argue that there is substantial precedent for this as a system default, or that more consumers of the software will benefit from advertising version information than otherwise. What this suggests is that we should look for a compromise. The first that comes to mind is to make it possible to configure the optional (non-protocol) component in the version string using a run-time configuration parameter, but for the default string (when unconfigured), we should make use of a version identifier. Just a proposal :-). Note that BIND used to require recompiling its version string, but now allows it to be changed using run-time parameters. 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.1010326205118.81313D-100000>