Debian Bug report logs - #786987
openssh-server: please have DebianBanner default to no

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: submit@bugs.debian.org

Subject: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 09:42:38 -0400

[Message part 1 (text/plain, inline)]

Package: openssh-server
Version: 1:6.7p1-6
Severity: wishlist

Please change the defaults for the DebianBanner configuration variable
to "no" from "yes".

It's not clear to me that the advantages of announcing the debian
version of the package that is running outweigh the additional metadata
leakage.

An administrator capable of upgrading packages when needed (e.g. for
security updates) should have more reliable ways to learn the version of
openssh-server running on their system than a cleartext banner sent
across the network on port 22.  And for systems that are not updated as
frequently as they should be, announcing "i have not yet been patched"
seems like an invitation for scripted attack the next time an
exploitable vulnerability is announced.

Thanks for maintaining OpenSSH in debian!

Regards,

            --dkg

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 786987@bugs.debian.org

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 15:38:52 +0100

On Wed, May 27, 2015 at 09:42:38AM -0400, Daniel Kahn Gillmor wrote:
> Please change the defaults for the DebianBanner configuration variable
> to "no" from "yes".
> 
> It's not clear to me that the advantages of announcing the debian
> version of the package that is running outweigh the additional metadata
> leakage.

I've always disagreed with this, which is why the banner default is the
way it is.  In particular, I've generally seen very little in the way of
evidence that people actually bother to select the servers they're going
to attack based on the banner, rather than just scattergunning the
attack across every server they can find.

> An administrator capable of upgrading packages when needed (e.g. for
> security updates) should have more reliable ways to learn the version of
> openssh-server running on their system than a cleartext banner sent
> across the network on port 22.

The specific case that prompted the banner in the first place was that
of a university trying to ensure that systems on its network was secure,
where the central administration doesn't have direct access to upgrade
packages nor any other such reliable way to determine package versions,
but does have the ability to disconnect vulnerable systems if need be.

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #15 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Colin Watson <cjwatson@debian.org>, 786987@bugs.debian.org

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 17:44:02 +0200

[Message part 1 (text/plain, inline)]

On Wed, 2015-05-27 at 15:38 +0100, Colin Watson wrote: 
> I've always disagreed with this, which is why the banner default is the
> way it is.  In particular, I've generally seen very little in the way of
> evidence that people actually bother to select the servers they're going
> to attack based on the banner, rather than just scattergunning the
> attack across every server they can find.

From a security POV I'd tentatively agree with Colin,...
DKG, do you have any stronger reasons why you'd think an attacker could
take benefit of this? E.g. are there attacks which take considerable
time and where knowledge whether the server was vulnerable would thus
help?


But...

> The specific case that prompted the banner in the first place was that
> of a university trying to ensure that systems on its network was secure,
> where the central administration doesn't have direct access to upgrade
> packages nor any other such reliable way to determine package versions,
> but does have the ability to disconnect vulnerable systems if need be.

Here I have to disagree with Colin.
The purpose of the SSH has never been to do package management and/or
Nagios-like tasks like software version reporting.
If big sites want to monitor their current SSH version state they should
better use the tools made for it (check_apt or whatever).

The version in it is purely for protocol compatibility reasons.
Thus, the DebianBanner should have never gotten in and from an
engineering PoV it's not only pretty much useless but should be rather
removed.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #20 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>, 786987@bugs.debian.org

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 16:58:54 +0100

On Wed, May 27, 2015 at 05:44:02PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-05-27 at 15:38 +0100, Colin Watson wrote: 
> > The specific case that prompted the banner in the first place was that
> > of a university trying to ensure that systems on its network was secure,
> > where the central administration doesn't have direct access to upgrade
> > packages nor any other such reliable way to determine package versions,
> > but does have the ability to disconnect vulnerable systems if need be.
> 
> Here I have to disagree with Colin.
> The purpose of the SSH has never been to do package management and/or
> Nagios-like tasks like software version reporting.
> If big sites want to monitor their current SSH version state they should
> better use the tools made for it (check_apt or whatever).

Nagios is fine if you're running a server farm.  It's useless if your
purpose is to perform friendly probing of a large heterogeneous network
most of which consists of desktop-type systems not run by professional
sysadmins.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #25 received at 786987@bugs.debian.org (full text, mbox, reply):

From: ilf <ilf@zeromail.org>

To: 786987@bugs.debian.org

Subject: Re: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 18:45:50 +0200

[Message part 1 (text/plain, inline)]

I agree with dkg. In an age where we know that nation-state actors ath 
the same time kill people based on metadata and target Angry Birds, we 
should do all we can to minimize revealing metadata by default.

I can see no real protocol reason why the DebianBanner exists. If Sysads 
want to enable that - fine, go head. But it shouldn't be default, unless 
it breaks a core functionality of OpenSSH. Which it doesn't.

-- 
ilf

Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
		-- Eine Initiative des Bundesamtes für Tastaturbenutzung

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Colin Watson <cjwatson@debian.org>

Cc: 786987@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 18:59:33 +0200

[Message part 1 (text/plain, inline)]

On Wed, 2015-05-27 at 16:58 +0100, Colin Watson wrote: 
> Nagios is fine if you're running a server farm.  It's useless if your
> purpose is to perform friendly probing of a large heterogeneous network
> most of which consists of desktop-type systems not run by professional
> sysadmins.
We have thousands of nodes at the university,.. within clusters, as
workstations and dedicates experiment servers...

For none of them we use the Banner to determine whether it's up to
date... is the banner not even secured? If not this would be completely
useless to check whether an installation is "secure" as an attacker
could simply try to forge the banner.

Anyway... even for desktop nodes there are better ways (including nagios
and loads of other apt notifiers/etc.) to keep software up to date...


Anyway... I don't think this is that much of an security issue - but
since there could be attacks where it's helpful to know the exact
version in order to save time... better remove it than being sorry
later.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #35 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>

Cc: 786987@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 18:29:07 +0100

On Wed, May 27, 2015 at 06:59:33PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-05-27 at 16:58 +0100, Colin Watson wrote: 
> > Nagios is fine if you're running a server farm.  It's useless if your
> > purpose is to perform friendly probing of a large heterogeneous network
> > most of which consists of desktop-type systems not run by professional
> > sysadmins.
> We have thousands of nodes at the university,.. within clusters, as
> workstations and dedicates experiment servers...

Surely you understand that it depends very strongly on the type of
management in place.  If not, please stop replying to this bug.

> For none of them we use the Banner to determine whether it's up to
> date... is the banner not even secured? If not this would be completely
> useless to check whether an installation is "secure" as an attacker
> could simply try to forge the banner.

That's a completely different kind of attack.

> Anyway... I don't think this is that much of an security issue - but
> since there could be attacks where it's helpful to know the exact
> version in order to save time...

Like I say, I'm not aware of this being an issue in practice.  If you
know real details, then instead of replying to this bug with hypotheses,
please point me at real examples.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #40 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <calestyo@scientia.net>

To: Colin Watson <cjwatson@debian.org>

Cc: 786987@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 19:33:12 +0200

[Message part 1 (text/plain, inline)]

On Wed, 2015-05-27 at 18:29 +0100, Colin Watson wrote: 
> Like I say, I'm not aware of this being an issue in practice.  If you
> know real details, then instead of replying to this bug with hypotheses,
> please point me at real examples.
As I've said... I (personally) don't feel that concerned about this
specific issue - we have other much more serious security problems in
OpenSSH.

I guess DKG's idea simply was that we shouldn't wait for an example case
where an attacker may abuse this (simply because it's too late then),
but proactively change it now.


Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Message #45 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Christoph Anton Mitterer <calestyo@scientia.net>

Cc: 786987@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Wed, 27 May 2015 18:43:47 +0100

On Wed, May 27, 2015 at 07:33:12PM +0200, Christoph Anton Mitterer wrote:
> As I've said... I (personally) don't feel that concerned about this
> specific issue - we have other much more serious security problems in
> OpenSSH.

OK, but you took the trouble to reply to this bug to disagree in the
first place. :-)

> I guess DKG's idea simply was that we shouldn't wait for an example case
> where an attacker may abuse this (simply because it's too late then),
> but proactively change it now.

I would normally sympathise with that.  In this case, though, the
original rationale for the change allowed real admins to avoid worrying
about a bunch of machines that had clearly already been upgraded, and
spend time on dealing with getting the people running out-of-date
machines to upgrade; when talking about thousands of heterogeneous
student-run machines that's a win for overall security even if it isn't
as dramatic as an exploit.  So I'm in a position where I have real-world
information on one side and hypotheticals on the other, which makes the
hypotheticals less convincing.  I hope that makes my position a bit
clearer.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #50 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Micah Anderson <micah@debian.org>

To: 786987@bugs.debian.org

Subject: evidence

Date: Thu, 04 Jun 2015 10:35:37 -0400

[Message part 1 (text/plain, inline)]

Hi,

I hear the argument that Colin is making, and understand and respect the
use-case he describes for the setting, and wouldn't argue that this
option should be removed. However, I feel like the comparison that is
being setup doesn't make sense for justifying that the setting is the
default.

The argument is basically that we should use the current setting as the
default for everyone, because there is one specific use-case that
justifies it. While the argument against reverting this default is that
there isn't any specific evidence of people using the version string to
select servers for attack.

I think that is much easier to come up with an actual use-case for the
first, but much harder to provide concrete evidence of the latter. That
isn't necessarily because this never happens, but very possibly its
because it is quite hard to provide specific evidence of this being
used, regardless if it is actually being done.

We do know, in general, where this version string is used in ways that
are undesirable:

 . it is a module in metasploit for helping identify vulnerable
 versions[0]

. it is used as a selector in NSA's XKEYSCORE queries in conjunction
 with the metadata database of potentially exploitable services
 (BLEAKINQUIRY) by the NSA group "S31176" for targeted exploit and
 compromise[1][2]

. it is used by annoying "security" scanners, such as Nessus to
 incorrectly identify vulnerable versions <-- I would normally argue
 that version strings are a terrible way of finding an actual
 vulnerability, in fact I *regularly* have to argue with people who run
 these "security" scanners against our network and then bring us a
 report to show me how many "vulnerable" services we have because the
 version numbers in their outdated database don't take into account
 Debian Security fixes... but this is precisely why I am bringing this
 up, because I have to regularly argue with people about these version
 strings. They are wrong, of course, but I don't want to have to deal
 with that pointless argument. If there was no version string, I
 wouldn't have to do that anymore.

. its used in CTF (capture the flag) events, in order to know what OS is
running on a system that only has ssh running, and what version of ssh
is running so that you can look at exploits that could be used to
compromise the system for a flag.

apart from these, things like malware dropper (for instance) that use
0-days don't bother with version strings, they just hammer the internet
and try it anyways... but that depends a lot on the malware.

I'd actually turn that argument around and say that justifying Debian
carrying this patch and setting this non-standard default from upstream
for everyone, just because of one example, is not sufficient.

micah

0. http://www.offensive-security.com/metasploit-unleashed/Service_Identification
1. http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
2. http://www.spiegel.de/media/media-35515.pdf

[signature.asc (application/pgp-signature, inline)]

Message #55 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Micah Anderson <micah@debian.org>, 786987@bugs.debian.org

Subject: Re: Bug#786987: evidence

Date: Thu, 4 Jun 2015 16:22:01 +0100

On Thu, Jun 04, 2015 at 10:35:37AM -0400, Micah Anderson wrote:
> . it is used as a selector in NSA's XKEYSCORE queries in conjunction
>  with the metadata database of potentially exploitable services
>  (BLEAKINQUIRY) by the NSA group "S31176" for targeted exploit and
>  compromise[1][2]

This is a somewhat more compelling argument; I'll think about it.

> . it is used by annoying "security" scanners, such as Nessus to
>  incorrectly identify vulnerable versions <-- I would normally argue
>  that version strings are a terrible way of finding an actual
>  vulnerability, in fact I *regularly* have to argue with people who run
>  these "security" scanners against our network and then bring us a
>  report to show me how many "vulnerable" services we have because the
>  version numbers in their outdated database don't take into account
>  Debian Security fixes... but this is precisely why I am bringing this
>  up, because I have to regularly argue with people about these version
>  strings. They are wrong, of course, but I don't want to have to deal
>  with that pointless argument. If there was no version string, I
>  wouldn't have to do that anymore.

But that's exactly why DebianBanner was introduced: so that it's
*possible* for such scanners to distinguish fixed versions, given
knowledge of our security updates, and to give you a reasonable argument
for the security folks in your organisation to leave you alone once
you've applied updates.

Upstream's non-configurable default is to include the OpenSSH version in
the banner (e.g. "OpenSSH_6.8p1").  DebianBanner merely makes this more
fine-grained.  You're asking for something quite different here, which
is https://bugzilla.mindrot.org/show_bug.cgi?id=764; but that's WONTFIX
upstream for good reason, because it's still necessary to use the
version for protocol compatibility tweaks.  The most recent version of
itself that OpenSSH needs to distinguish in this manner is as recent as
6.6p1, to deal with a key exchange bug in its implementation of ED25519,
and something different comes along here every couple of years or so;
this is not an archaic thing that can safely be discarded.

As such, the best that we can do without causing real and significant
interoperability problems is to advertise "SSH-2.0-OpenSSH_6.7p1" rather
than "SSH-2.0-OpenSSH_6.7p1 Debian-5" in our banner.  You'll still have
to argue with people about these version strings; in fact, if you're
having to do so right now, disabling DebianBanner will almost certainly
cause you to have to do so more often.

> . its used in CTF (capture the flag) events, in order to know what OS is
> running on a system that only has ssh running, and what version of ssh
> is running so that you can look at exploits that could be used to
> compromise the system for a flag.

Yeah, though dealing with this seems like a drop in the ocean compared
to things like TCP stack fingerprinting that are much harder to address.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #60 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@debian.org>

To: Colin Watson <cjwatson@debian.org>, Micah Anderson <micah@debian.org>, 786987@bugs.debian.org

Subject: Re: Bug#786987: evidence

Date: Thu, 04 Jun 2015 17:35:23 -0400

On Thu 2015-06-04 11:22:01 -0400, Colin Watson wrote:
> On Thu, Jun 04, 2015 at 10:35:37AM -0400, Micah Anderson wrote:
>> . it is used as a selector in NSA's XKEYSCORE queries in conjunction
>>  with the metadata database of potentially exploitable services
>>  (BLEAKINQUIRY) by the NSA group "S31176" for targeted exploit and
>>  compromise[1][2]
>
> This is a somewhat more compelling argument; I'll think about it.

Thanks, Colin  :)

> Upstream's non-configurable default is to include the OpenSSH version in
> the banner (e.g. "OpenSSH_6.8p1").

Hm, i think Upstream's non-configurable default is actually
"SSH-2.0-OpenSSH_6.8" (even in the portable version).  Debian has added
the trailing "p1" in debian/patches/package-versioning.patch.

> https://bugzilla.mindrot.org/show_bug.cgi?id=764; but that's WONTFIX
> upstream for good reason, because it's still necessary to use the
> version for protocol compatibility tweaks.  The most recent version of
> itself that OpenSSH needs to distinguish in this manner is as recent
> as 6.6p1, to deal with a key exchange bug in its implementation of
> ED25519, and something different comes along here every couple of
> years or so; this is not an archaic thing that can safely be
> discarded.

Yeah, that part is too bad, and the bug was present in 6.5 and 6.6
before being fixed in 6.7.  one approach to getting roughly the same
functionality would be to have a version-independent
"incompatible-feature" string announced in the header; so upon the
bugfix, you'd add "fixed-25519-dh" (or just "N", where N is a
monotonically increasing number that indicates the set of OpenSSH
accumulated signalling-worthy-fixes, which are assumed to all be
applied) -- it doesn't have to be updated with each version.

(and the worst that happens with the bug you mention is a 0.2% chance of
handshake failure with unpatched peers, fwiw; this might be a cost some
people are willing to bear for the sake of minimizing leakage)

But anyway, this bug report is specifically about the default for
DebianBanner, not about removing the upstream version string.

> As such, the best that we can do without causing real and significant
> interoperability problems is to advertise "SSH-2.0-OpenSSH_6.7p1" rather
> than "SSH-2.0-OpenSSH_6.7p1 Debian-5" in our banner.  You'll still have
> to argue with people about these version strings; in fact, if you're
> having to do so right now, disabling DebianBanner will almost certainly
> cause you to have to do so more often.

Colin is certainly right here, but if micah has turned off DebianBanner
on his servers, he's probably already dealing with that situation.

>> . its used in CTF (capture the flag) events, in order to know what OS is
>> running on a system that only has ssh running, and what version of ssh
>> is running so that you can look at exploits that could be used to
>> compromise the system for a flag.
>
> Yeah, though dealing with this seems like a drop in the ocean compared
> to things like TCP stack fingerprinting that are much harder to address.

Fixing TCP stack fingerprinting is not in scope for the OpenSSH package,
though.  And someone trying to fix TCP stack fingerprinting might not
bother because "hey, the OS and version info are all leaked by apache
and OpenSSH anyway, why should we bother?"

Helping to resolve tricky issues like fingerprinting is a collective
action problem, and each part of the ecosystem needs to improve.  I know
you understand this, Colin, but i don't want the "don't bother fixing X
because Y is also broken" argument to get traction.  In an environment
as ugly and broken as the Internet, that just leads to despair and
complete inaction :)

Thanks for the consideration here,

       --dkg

Message #65 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 786987@bugs.debian.org

Subject: make it preseedable?

Date: Tue, 16 Jun 2015 17:40:31 +0200

[Message part 1 (text/plain, inline)]

Hi,

I'd also like my hosts not to show the DebianBanner, but I can also see how 
people want that. And I think there are several packages with features like 
that, where one group expects the feature to be on and another group expects 
it to be off.

So I came to think it would be nice if such a feature would be preseedable and 
then there could be other packages to be installed to express which group one 
belongs to. Kind of like "apt-get install hardening" which (as a fictionous 
example) enables hardening for packages there could be "apt-get install 
privacy-aware-services" or "apt-get install maintenance-friendly-services" or 
such.

Preseeding makes such reconfiguration easily and programmatically possible.


cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #70 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: Colin Watson <cjwatson@debian.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 786987@bugs.debian.org

Subject: Re: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Mon, 22 Feb 2016 16:19:24 +0100

[Message part 1 (text/plain, inline)]

On 27/05/15 16:38, Colin Watson wrote:
>> An administrator capable of upgrading packages when needed (e.g. for
>> security updates) should have more reliable ways to learn the version of
>> openssh-server running on their system than a cleartext banner sent
>> across the network on port 22.
> 
> The specific case that prompted the banner in the first place was that
> of a university trying to ensure that systems on its network was secure,
> where the central administration doesn't have direct access to upgrade
> packages nor any other such reliable way to determine package versions,
> but does have the ability to disconnect vulnerable systems if need be.
> 
> Cheers,
> 

So, putting it into other words...  The use case was actually to make
easier to detect vulnerable systems to anyone without access to the
system by inspecting the DebianBanner version of the SSH servers, right?

Is this use case (announcing vulnerable machines via the SSH server
DebianBanner info to anyone without access rights to the machine)
something that Debian wants to keep supporting by default???? I'm astonished

[signature.asc (application/pgp-signature, attachment)]

Message #75 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Carlos Alberto Lopez Perez <clopez@igalia.com>, 786987@bugs.debian.org

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Mon, 22 Feb 2016 15:30:20 +0000

On Mon, Feb 22, 2016 at 04:19:24PM +0100, Carlos Alberto Lopez Perez wrote:
> So, putting it into other words...  The use case was actually to make
> easier to detect vulnerable systems to anyone without access to the
> system by inspecting the DebianBanner version of the SSH servers, right?

People can do that anyway just by seeing whether their attacks work;
plenty of actual attackers just scattergun their attacks.  Hiding the
version doesn't particularly help, but giving network administrators the
ability to efficiently shut off access to vulnerable systems can do.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #80 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: Colin Watson <cjwatson@debian.org>, 786987@bugs.debian.org

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Mon, 22 Feb 2016 16:47:40 +0100

[Message part 1 (text/plain, inline)]

On 22/02/16 16:30, Colin Watson wrote:
> On Mon, Feb 22, 2016 at 04:19:24PM +0100, Carlos Alberto Lopez Perez wrote:
>> So, putting it into other words...  The use case was actually to make
>> easier to detect vulnerable systems to anyone without access to the
>> system by inspecting the DebianBanner version of the SSH servers, right?
> 
> People can do that anyway just by seeing whether their attacks work;
> plenty of actual attackers just scattergun their attacks.  Hiding the
> version doesn't particularly help, 

I disagree.

If some attacker knows that (for example) that
openssh-server=1:6.7p1-5+deb8u is vulnerable to any vulnerability, they
can find instantly thousands of hosts to attack directly by doing
something as easy as this:

https://www.shodan.io/search?query=SSH-2.0-OpenSSH_6.7p1+Debian-5%2Bdeb8u1

And if they want to find hosts running on Debian lenny (that probably
contains many unpatched vulnerabilities), they can do this:

https://www.shodan.io/search?query=SSH-2.0-OpenSSH_5.1p1+Debian-5

So, this leak on information helps a *lot* to any attacker targeting
specific versions of unpatched software.


Attackers usually don't start trying to probe exploit after exploit.
That is silly. They are probably going to be detected by some IDS or
something like that. The first thing an attacker is going to do is to
gather information about what you are running and which versions. And
this default is helping them a lot.

> but giving network administrators the
> ability to efficiently shut off access to vulnerable systems can do.
>

I think that any network administrator having to do this to secure their
own network probably has a bigger problem that insecure hosts on their
network.

In any case I'm not going to argue about this. We are talking about a
default.

How much network administrators have this need?

And how many Debian users are leaking information about their insecure
machines making them much more exposed to attackers targeting old
versions of the software they run?

So, I think the default should be to have this option to be No.

And the burden should be on the network administrator of your use case
to tell users to enable this option or he will disconnect them.

[signature.asc (application/pgp-signature, attachment)]

Message #85 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Carlos Alberto Lopez Perez <clopez@igalia.com>

Cc: Colin Watson <cjwatson@debian.org>, 786987@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Mon, 22 Feb 2016 09:27:31 -0800

Carlos Alberto Lopez Perez <clopez@igalia.com> writes:

> Attackers usually don't start trying to probe exploit after exploit.

Of course they do.  That is, *by far*, the most common attacker strategy
on the Internet.  Just look at the logs of any Internet-facing service.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #90 received at 786987@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: Russ Allbery <rra@debian.org>

Cc: Colin Watson <cjwatson@debian.org>, 786987@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#786987: Re: Bug#786987: openssh-server: please have DebianBanner default to no

Date: Mon, 22 Feb 2016 18:43:21 +0100

[Message part 1 (text/plain, inline)]

On 22/02/16 18:27, Russ Allbery wrote:
> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
> 
>> Attackers usually don't start trying to probe exploit after exploit.
> 
> Of course they do.  That is, *by far*, the most common attacker strategy
> on the Internet.  Just look at the logs of any Internet-facing service.
> 

Yes, there are some attackers that do silly things like that. And since
they make lot of noise they appear also a lot on the logs.

But it happens that there are also intelligent attackers out there. They
will first try to find hosts running the affected version that their
exploit targets. This last ones are usually more successful and you
won't see them in the logs of any Internet-facing service because they
don't make noise trying exploit after exploit.

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.