Bug#786987: evidence
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
Reply to: