On 10/02/02, Lazarus Long wrote:
> On Sat, Jan 26, 2002 at 12:25:08PM +0000, Matthew Vernon wrote:
> > Lazarus Long writes:
> > > Introduces security hole by divulging too much information to an
> > > attacker about the underlying system.
> > The rationale behind this, is that there are many instances where it
> > is useful for a network admin to know whether the sshd on a particular
> > machine is secure or not
> Of course it is "useful," Matthew, but that admin can do so, safely
> *logged in to* the machine in question, with the 'dpkg -l ssh' command
> I mentioned above. There is no need to advertise any vulnerabilities
> to those *outside* the machine.
So if you have more then 50 machines in your network to administrate
which run debian, you will login into every machine typing always your
passphrase or the password just to run dpkg -l ssh to find out which
version of ssh is used on that machine? And ssh-agent is not a good
solution here, because it might expose your passphrase or other
important information.
> > - in stable, our version of sshd gives out a version string identical
> > to a very insecure upstream version, yet is patched.
> How is this in any way relevant?
How shall an administrator from knowing just the version number of the
sshd itself be sure that this machine runs a patched and therefor secure
version of the client without having to use the procedure I described
above?
> > I reject the security-by-obscurity claim you make - attackers don't
> Again, security-by-obscurity (which you seem to be parroting from
> another misinformed individual in this thread) is properly used to
> refer to *source code* availability, for peer review within the crypto
> community, not the specifics of any given machine's implementation.
No, I don't agree with you here. Security-by-obscurity doesn't only
refer to those cases, but also to other problems. It's a common used
term to describe a situation where one achieves security by witholding
information.
> (I refer you to my comment about "post your root password and IP address
> if you think obscurity is irrelevant.")
And that helps you how much if the machine wants a passphrase or an
otp-key?
> I will include a quote at the end of this message from an appropriate
> source, if this will help to further understanding.
> > care what OS you're running often, they just try everything on the
> > network. Furthermore, it is trivial [queso(8)] to find out what OS
> Running queso against four different machines here returns either the
> erroneous "* Standard: Solaris 2.x, Linux 2.1.???, MacOS" or else
> "*- Not Listen, try another port". None of those machines run any
> of the operating systems queso reported.
And when then don't you start reading either queso -h or man queso to
find out how to use it?
> > Besides, if version x of upstream has bug y, and Debian package x-n of
> > upstream version x hasn't, then what do you care if someone tries the
> > exploit on you?
> And what about the opposite scenario? Debian has very recently taken
> months to close a known security hole, without telling the end-users,
And how many security holes have been fixed in a timely manner by
Debian? Picking out one bad example is easy, but you need to look at in
relation to the many security fixes that have been released much sooner.
> > Unless you can produce a more convincing argument, I intend to close
> > this bug.
> Since my own words seem to have been inadequate in the past, I'll paste
> here a fair-use excerpt from the most recent book from a widely-known
> and highly-regarded authority in the computer security (and crypto)
> field, whom I hope you will recognize.
> This excerpt is taken from p. 371f of Bruce Schneier's _Secrets and Lies,
> Digital Security in a Networked World_ (Wiley and Sons, 2000)
> One of the strengths an attacker has is knowledge of the
> terrain. Just as an army doesn't broadcast the location of its tanks,
> anti-aircraft missiles, and battalions to the enemy, there's no reason
> to broadcast your network topology to everyone that asks. Too many
> computers respond to any query with their operating system and version
> number; there's no reason to give out this information. Much better
> would be a login screen that reads: "Warning: Proprietary Computer.
> Use of this system constitutes consent to security monitoring.
> All user activity is logged, including the hostname and IP address."
> Let the attackers wonder if you can trace them.
> ... An attacker shouldn't know what types of equipment are running
> where, what protocols are allowed under what conditions, what ports
> are open under what conditions. I am amazed by the number of servers,
> applications and protocols that announce themselves to the world:
> "Hello! I am randomservice V2.05." Many hacking (sic) tools scan
> for particular versions of software running on particular machines
> ... known to have particular vulnerabilities. If networks are
> unpredictable, attackers won't be able to wander around so freely.
> Without this kind of information, it's much harder to profile a
> target and determine what attacks to try. It's the difference between
> walking in a sunny meadow at midday and a briar patch at midnight.
So let's take a look at the current response of the sshd daemon:
|SSH-1.99-OpenSSH_3.0.2p1
So, first you would need to argue to remove the term OpenSSH and not
use it, because it reveals information that this is the OpenSSH client
and not the one from SSH Corporation or some other manufacturer. Next
you would need to argue for removing 3.0.2p1 which reveals the specific
information about the client version. So we now would have the following
string:
|SSH-1.99
This would still contain information about the protocols supported and
used by this instance of the ssh daemon, so that in the end you would
need to argue to replace the whole string
|SSH-1.99-OpenSSH_3.0.2p1
with the string
|SSH
which would reveal absolutely no information about this. I'm waiting to
see your argumentation about this on the openssh list. Otherwise this
looks for me much like you want to intimidate just the OpenSSH
maintainer of Debian instead of completely removing every important
information from the ssh daemon.
Christian
--
Debian Developer (http://www.debian.org)
1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8
Attachment:
pgp7hV36qye6N.pgp
Description: PGP signature