reopen 130876 severity 130876 grave thanks As I have said in the past, this is definitely a security risk. There is no reason that such information should be exposed to attackers.
'dpkg -l ssh' provides a Debian-specific version string, and there is no
reason this needs to be exposed to those who have no authority to access
the system. All I have heard from the proponents of this ridiculous
claim is "ease" (which of course is the same argument for password-less
root accounts, and is equally ridiculous.)
Quoting myself:
> /etc/issue and /etc/issue.net are conffiles, so the site admin can
> choose to stop broadcasting information to any and all attackers that
> may aid them in the process. Yet ssh 1:3.0.2p1-5 intends to make that
> irrelevant for any host running it on a public interface. This is
^^^^^^^^^^^^^^^^^^^^^
> a significant security hole that -5 opens, that was not open in -4,
> and needs to be addressed ASAP.
The "public interface" phrase emphasized above will be pertinent below.
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.
> - 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?
> 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.
(I refer you to my comment about "post your root password and IP address
if you think obscurity is irrelevant.")
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.
> you're running, and other programs such as Apache will say that it's
> Debian.
How many intended-to-be-secure machines run Apache? Typically, a machine
will run with sshd, and *only* sshd, listening on an outward-facing
interface. Consider the context in which this package is intended to be
deployed. (I hadn't expected to need to explain this to the maintainer
of this particular package.)
> 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,
after all. But again, something I hadn't thought I would need to
explain to the ssh package maintainer is that information about a given
machine (such as the fact that it runs Debian at all) gives the attacker
significant information about the system, *regardless* of whether the
ssh package itself is vulnerable or not. ("She's running Debian? Kewel,
that's the one with the vulnerable foo which I can now attack!" ("foo"
being glibc recently, or some other equally widely-deployed package in
the future, perhaps?))
> 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.
I will be forwarding a copy of this message to him (common courtesy,
after all) as well as the URL for the bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=130876&repeatmerged=yes)
in the hope that he will refute any misquotation or inappropriate
editing, implication, misleading, or misinterpretation on my part.
(Any present are unintentional and solely my own responsibility.)
<off-topic> Incidentally, I highly recommend the above book, it was both
informative and entertaining, as I had expected, having read (and *then*
purchased) _Applied Cryptography_. </off-topic>
Hopefully, if my own words have been inadequate to communicate this
concept, the above well-written ones will now suffice. The ssh package
should *assist* the admin who wants a secure machine, not *subvert*
the attempt.
> Well, I hear no disagreement, so I'm closing this bug now.
Sigh. (I'm not fast enough with the research behind this apparently.)
The above is disagreement for you to hear, and I'm now reopening it.
--
Please (OpenPGP) encrypt all mail whenever possible. Request the following
Public Keys for Lazarus Long <[EMAIL PROTECTED]>
Type Bits/KeyID Fingerprint DSA KeyID: vvvv vvvv
ElGamal: 2048g/CCB09D64 8270 4B79 CB1E 433B 6214 64EB 9D58 28A9 E8B1 27F4
(old 2001 keys)
ElGamal: 2048g/215A8B4A F258 C2DD 7E9C DCEB E64F 82EC D4BB 3438 8B82 A392
pgpzxnh8nmHv0.pgp
Description: PGP signature
