From owner-freebsd-security Tue Mar 27 14:30:52 2001 Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 549AC37B71E for ; Tue, 27 Mar 2001 14:30:42 -0800 (PST) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id QAA22647; Tue, 27 Mar 2001 16:30:40 -0600 (CST) (envelope-from jeff-ml@mountin.net) Received: from dial-59.tnt1.rac.cyberlynk.net(209.224.182.59) by peak.mountin.net via smap (V1.3) id sma022632; Tue Mar 27 16:30:11 2001 Message-Id: <4.3.2.20010327160147.02c1b6c0@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Mar 2001 16:27:55 -0600 To: Garance A Drosihn From: "Jeffrey J. Mountin" Subject: Re: SSHD revelaing too much information. Cc: security@FreeBSD.ORG In-Reply-To: References: <20010327005503.J5425@rfx-216-196-73-168.users.reflex> <20010327005503.J5425@rfx-216-196-73-168.users.reflex> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:08 PM 3/27/01 -0500, Garance A Drosihn wrote: CC;s trimmed... >>The 'green@FreeBSD.org 20010321' is too much information. The >>'OpenSSH_2.3.0' part is required for the protocol. > >My apologies, I worded that really stupidly. At the very >least, there should have been an 'extra' in what I said... > >My thought was that the EXTRA version information would be >displayed after authentication was complete. Ie, send the >'OpenSSH_2.3.0' part where the protocol needs it, and send >the 'green@FreeBSD.org 20010321' part (perhaps with even >more details) in the output of '-v'. I've been doing a >lot of 'ssh -v'-ing lately, as I set up some new hosts, >so this seemed an obvious way to make the info available. >The EXTRA info, I mean... :-) > >The idea would be to give administrators the ability to >easily determine the precise version info, without giving >"unknown outsiders" (ie, unauthenticated connections) >that information. You also forget the point that the extra information means it isn't a vulnerable version, which it would be without the patches. Thus moving that information later would mean a potential attacker might think "Hey, this system is vulnerable..." and try to exploit a hole that has been plugged. Believe doing this would annoy far more people than those that are complaining about the information. Blah! Displaying the extra version string info later on would be pointless, not to mention require the "normal" version string, and a lot of work for a false sense of security. Personally think that if you don't like the version string for any service then it is up to the person that doesn't want it to alter the source themselves. Anything else is just a waste of developer time. Something that no has pointed out yet is that if you try to limit the information the system displays or not for that matter, you might attract the attention of someone that likes a challenge. Sure there are far more script kiddies, but would lump the obscurity idea along with boasting a system is not vulnerable. Bragging might attract the wrong types to test the truth of such a statement. For certain that might help when it turns out it isn't true, but would be a hassle regardless. I'm for limiting information to an extent. However, it seems this and similar ideas are argued by those that cannot do the work themselves or are too lazy to bother. There is also the law of diminishing returns, which IMO such time would be better spent elsewhere than trying to hide behind minimal information or talking about such things and not offering up any patches. In this case to the OpenSSL folks, so that they do not have to be maintained locally by the maintainer. Thinking at times there should be a security methodology list... Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message