Debian Bug report logs - #765632
openssh-client: Debian shouldn't deviate in hardcoded default values, especially not ForwardX11Trusted

Reply or subscribe to this bug.

Toggle useless messages

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

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

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: openssh-client: Debian shouldn't deviate in hardcoded default values, especially not security relevant one

Date: Thu, 16 Oct 2014 20:47:00 +0200

Package: openssh-client
Version: 1:6.7p1-2
Severity: important
Tags: security


Hi.

Apparently Debian deviates in a few of OpenSSH's hardcoded default
settings, namely:
- ForwardX11Trusted having set to yes
- ServerAliveInterval being set to 300, when BatchMode is set to yes.

Even though I've read that before it wasn't clear to me, that you just
changed the values in the default config files but really the hard coded
ones in the binary.

Especially for ForwardX11Trusted this seems a security issue to me, since
you change to the insecure mode.
Even if there was any good reason for this (why btw?)... no one expects
this, i.e. no one comming from non-Debian, and while one can probably
demand admins and users to check their *config files* for different
defaults on different platforms, one cannot expect that people re-read
all manpages whether the program options themselves have changed;
especially not in the case of well-known programs like ssh, which behave
differently in every other place.

I would perhaps agree to such step, if it closes a security issue but
this acutally opens one (long story short: we've had an attack here in
the faculty on two nodes from a compromised machine, which was at least
made easier by this). :(


I don't have that strong feelings about ServerAliveInterval/BatchMode,
since I wouldn't see at least any direct way how to exploit this in terms
of security.
Yet I still think that such deviation is bad since everyone expects it
not to happen,.. and there may be programs who expect the connection
to remain open (and perhaps resume) and Debian sets a timeout which doesn't
exist anywhere else.
A proper solution would have been to add a new option like:
DefaultBatchModeServerAliveInterval, which defaults to the same
value as upstream (0) but which could be set to e.g. your 300s.
Then this option could have been set in a Debian's default ssh_config
an be used properly.



That being said, could you possibly do the following:
1) No longer change the hard coded default of ForwardX11Trusted
but rather add a ForwardX11Trusted=yes in new default ssh_config.
Or completely stop seting it, if there is no longer any reason for it.
For legacy users (who may be surprised) a NEWS entry should be added.

2) For ServerAliveInterval/BatchMode, I would suggest my solution
above, again with a NEWS entriy.
But as said, it's less important here.


Thanks,
Chris.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_DE.utf8, LC_CTYPE=en_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-client depends on:
ii  adduser           3.113+nmu3
ii  dpkg              1.17.18
ii  libc6             2.19-11
ii  libedit2          3.1-20140620-2
ii  libgssapi-krb5-2  1.12.1+dfsg-10
ii  libselinux1       2.3-2
ii  libssl1.0.0       1.0.1j-1
ii  passwd            1:4.2-2+b1
ii  zlib1g            1:1.2.8.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1

Versions of packages openssh-client suggests:
pn  keychain      <none>
pn  libpam-ssh    <none>
pn  monkeysphere  <none>
pn  ssh-askpass   <none>

-- no debconf information

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

From: Gerfried Fuchs <rhonda@deb.at>

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

Subject: Re: Bug#765632: openssh-client: Debian shouldn't deviate in hardcoded default values, especially not security relevant one

Date: Fri, 17 Oct 2014 13:31:22 +0200

      Hi!

* Christoph Anton Mitterer <calestyo@scientia.net> [2014-10-16 20:47:00 CEST]:
> Apparently Debian deviates in a few of OpenSSH's hardcoded default
> settings, namely:
> - ForwardX11Trusted having set to yes
> - ServerAliveInterval being set to 300, when BatchMode is set to yes.
> 
> Even though I've read that before it wasn't clear to me, that you just
> changed the values in the default config files but really the hard coded
> ones in the binary.
> 
> Especially for ForwardX11Trusted this seems a security issue to me, since
> you change to the insecure mode.
> Even if there was any good reason for this (why btw?)...

 This is documented and explained in the documentation in
/usr/share/doc/openssh-client/README.Debian.gz and also referenced from
the changelog.Debian.gz file, which is the canonical point to look at
for changes within the Debian packaging.

> I don't have that strong feelings about ServerAliveInterval/BatchMode,
> since I wouldn't see at least any direct way how to exploit this in terms
> of security.

 The following patch does this:

http://sources.debian.net/src/openssh/1:6.7p1-2/debian/patches/keepalive-extensions.patch/

 This is just an informal response.  I am not related to the packaging
of openssh, just wanted to point out where those things come from.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los      |
Fühlst du dich hilflos, geh raus und hilf, los    | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los    |

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

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

To: 765632@bugs.debian.org

Subject: Re: Bug#765632: openssh-client: Debian shouldn't deviate in hardcoded default values, especially not security relevant one

Date: Fri, 17 Oct 2014 17:30:16 +0200

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

Hi Gerfried

On Fri, 2014-10-17 at 13:31 +0200, Gerfried Fuchs wrote: 
>  This is documented and explained in the documentation in
> /usr/share/doc/openssh-client/README.Debian.gz and also referenced from
> the changelog.Debian.gz file, which is the canonical point to look at
> for changes within the Debian packaging.
Well I didn't say that it would be nowhere documented... and if it would
be just set in the config files, it would be okay (still a bit strange
because the default would enable less security, but okay...).
But no one coming from another system, perhaps logging again just via
SSH can be expected to read through all Debian manpages, README.Debian
files etc., just to find out whether the internal program defaults
themselves have been change.
I wouldn't want to log in to another system, just to see that rm
defaults to -r or something strange like that.

Quoting from README.Debian:
>OpenSSH 3.8 invented ForwardX11Trusted, which when set to no causes the
>ssh client to create an untrusted X cookie so that attacks on the
>forwarded X11 connection can't become attacks on X clients on the
>remote machine. However, this has some problems in implementation -
> notably a very short timeout of the untrusted cookie - breaks large
> numbers of existing setups, and generally seems immature. The Debian
> package therefore sets the default for this option to "yes" (in ssh
> itself,rather than in ssh_config).

I don't see why this issues shouldn't be adequately fixed by just
setting it in ssh_config and at least in the meantime, the timout is
apparently configuralbe (ForwardX11Timeout),... defaults to 20
minutes... and so far I haven't found any X client, which couldn't start
when ForwardX11Trusted=no - maybe I just picked the wrong.



>  The following patch does this:
> http://sources.debian.net/src/openssh/1:6.7p1-2/debian/patches/keepalive-extensions.patch/
Sure, I saw that myself, once I've noted that there are differences from
upstream... but I guess no one installs a package, and starts looking
for such differences, at least not in command line option defaults.


Cheers,
Chris.

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

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

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

To: 765632@bugs.debian.org

Subject: Re: Bug#765632: openssh-client: Debian shouldn't deviate in hardcoded default values, especially not security relevant one

Date: Fri, 17 Oct 2014 17:36:09 +0200

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

On Fri, 2014-10-17 at 13:31 +0200, Gerfried Fuchs wrote: 
>  This is documented and explained in the documentation in
> /usr/share/doc/openssh-client/README.Debian.gz

btw: at least parts of that file seem to be outdated:

Authorization Forwarding -> setting this to "no" seems to be just the
plain default upstream.

Fallback to RSH -> is this still in ssh?




Cheers,
Chris.

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

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

From: Philip Hands <phil@hands.com>

To: 765632@bugs.debian.org

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

Subject: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Sun, 22 Feb 2015 22:31:08 +0000

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

Hi,

This bug got mentioned on the  openssh-unix-dev mailing list yesterday,
so I had a look.

The primary thrust of this report seems to be about the modification
From upstream of the default for ForwardX11Trusted to now be set.

Frankly, I'm astonished by this -- I have been aware of -Y since it was
introduced, and had rather assumed that the fact that I was not using it
was offering me some degree of protection.  Yes, I can see now that it
gets a mention in the README.Debian, but I've managed to miss that for a
decade it seems.

However, in the place one might expect it to be documented (i.e. the ssh
man page) I see no mention of it.  In the ssh_config man page it gets
just:

  The default is “yes” (Debian-specific).

It seems to me it needs something along the lines of this near the -X
and -Y options' documentation:

  ***WARNING***

    -Y option is basically irrelevant as the result of Debian
       shipping a modified binary that treats -X the same way.
       You'll need to set ForwardX11Trusted to "no" if you want the
       documented behaviour that is provided upstream.

  *************

The patch that makes this change is here:

  http://sources.debian.net/src/openssh/1:6.7p1-3/debian/patches/debian-config.patch/

which includes mention of the fact that the change was introduced in
order to close this bug:

  https://bugs.debian.org/237021

where Colin states in  Message #47:

  I think it's become clear that it's too far-reaching at this point in
  Debian's release cycle; we need time to prepare the rest of the
  distribution for this sort of thing if it's to become the default.

That was in 2004 while Sarge was (not) getting released -- we've had
5 complete release cycles since then, so it might be time to get rid of
this patch.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

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

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

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

To: 765632@bugs.debian.org

Subject: Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Mon, 23 Feb 2015 00:00:10 +0100

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

On Sun, 2015-02-22 at 22:31 +0000, Philip Hands wrote: 
> The primary thrust of this report seems to be about the modification
> From upstream of the default for ForwardX11Trusted to now be set.
Well my mean reason, was actually more that Debian really changes some
default values in the program code, and not just in the default config
file delivered.

> Frankly, I'm astonished by this -- I have been aware of -Y since it was
> introduced, and had rather assumed that the fact that I was not using it
> was offering me some degree of protection.
While I agree that the default of ForwardX11Trusted seems to be pretty
ill-chosen, you have to remember that using X-forwarding is generally a
really bad idea from a security POV.


> Yes, I can see now that it
> gets a mention in the README.Debian, but I've managed to miss that for a
> decade it seems.
That's basically the point of my criticism... no one should need to read
through all Debian specific docs and manpages just to find all
deviations (especially when some are undocumented even there).


> However, in the place one might expect it to be documented (i.e. the ssh
> man page) I see no mention of it.  In the ssh_config man page it gets
> just:
> 
>   The default is “yes” (Debian-specific).
> 
> It seems to me it needs something along the lines of this near the -X
> and -Y options' documentation:
> 
>   ***WARNING***
> 
>     -Y option is basically irrelevant as the result of Debian
>        shipping a modified binary that treats -X the same way.
>        You'll need to set ForwardX11Trusted to "no" if you want the
>        documented behaviour that is provided upstream.
> 
>   *************

Nah,.. even that wouldn't be enough.
People shouldn't be expected to re-read the manpages of standard tools
for every new distro they log in to.
I mean what would come next? Swapping the meaning of -i and -f for rm,
with the excuse that this is documented somewhere (sorry for
exaggerating)?


Cheers,
Chris.

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

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

From: Colin Watson <cjwatson@debian.org>

To: Philip Hands <phil@hands.com>, 765632@bugs.debian.org

Cc: Christoph Anton Mitterer <calestyo@scientia.net>, debian-devel@lists.debian.org, debian-x@lists.debian.org

Subject: Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Wed, 19 Aug 2015 20:59:31 +0100

On Sun, Feb 22, 2015 at 10:31:08PM +0000, Philip Hands wrote:
> It seems to me it needs something along the lines of this near the -X
> and -Y options' documentation:
> 
>   ***WARNING***
> 
>     -Y option is basically irrelevant as the result of Debian
>        shipping a modified binary that treats -X the same way.
>        You'll need to set ForwardX11Trusted to "no" if you want the
>        documented behaviour that is provided upstream.
> 
>   *************
> 
> The patch that makes this change is here:
> 
>   http://sources.debian.net/src/openssh/1:6.7p1-3/debian/patches/debian-config.patch/
> 
> which includes mention of the fact that the change was introduced in
> order to close this bug:
> 
>   https://bugs.debian.org/237021
> 
> where Colin states in  Message #47:
> 
>   I think it's become clear that it's too far-reaching at this point in
>   Debian's release cycle; we need time to prepare the rest of the
>   distribution for this sort of thing if it's to become the default.
> 
> That was in 2004 while Sarge was (not) getting released -- we've had
> 5 complete release cycles since then, so it might be time to get rid of
> this patch.

I agree that this certainly needs better documentation, and I'll fix
that up.  Apologies for not having done that sooner.

I tried some experiments with ForwardX11Trusted=no today, and frankly,
it doesn't even pass the laugh test for usability.  Run xterm and try to
select something, bam, your xterm crashes with BadAccess.  Now, sure,
that's telling me that the X SECURITY extension forbids writing to the
selection, but giving client software a chance to catch up with the
expectation that it should handle such errors is exactly the kind of
reason that I chose to deviate from the upstream default in the first
place!  Now, I didn't do very exhaustive testing or anything, but to me,
those ten years haven't actually made a perceptible difference to how X
clients respond to failures from the SECURITY extension.

If I thought that this was actually useful, it might be worth the pain.
But at least I'm not the only one who thinks that this is a dubious
benefit for the pain it brings:

  https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

So: I don't think that this decision is realistically just up to me.  If
I change ssh back to use ForwardX11Trusted=no by default, a bunch of
other maintainers are going to be asked to fix their software in various
ways: the SECURITY extension may say no to something, but you might
reasonably expect that double-clicking in your terminal won't make it
explode in your face.  

debian-devel, debian-x, do you think that it's at all realistic to
expect clients to be fixed to handle such failures rather more
gracefully?

-- 
Colin Watson                                       [cjwatson@debian.org]

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

From: Josselin Mouette <joss@debian.org>

To: Colin Watson <cjwatson@debian.org>

Cc: Philip Hands <phil@hands.com>, 765632@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net>, debian-devel@lists.debian.org, debian-x@lists.debian.org

Subject: Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Wed, 19 Aug 2015 22:53:37 +0200

Le mercredi 19 août 2015 à 20:59 +0100, Colin Watson a écrit : 
> debian-devel, debian-x, do you think that it's at all realistic to
> expect clients to be fixed to handle such failures rather more
> gracefully?

Well, I guess it is possible, if we were to introduce appropriate error
checking in enough major toolkits.

At least in GTK3, I can tell you that it’s not here, and using untrusted
cookies will quickly make your applications crash.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

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

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

To: 765632@bugs.debian.org

Cc: debian-devel@lists.debian.org, debian-x@lists.debian.org

Subject: Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Wed, 19 Aug 2015 23:51:36 +0200

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

On Wed, 2015-08-19 at 20:59 +0100, Colin Watson wrote:
> I tried some experiments with ForwardX11Trusted=no today, and
> frankly,
> it doesn't even pass the laugh test for usability.

Well but it's ssh "Secure Shell" - and not ush (Usability Shell).
So the defaults should be always the secure ones, and not the fancy-out
-of-the-box™. :-)

I don't mind though, to leave the defaults as is in stable.


> Run xterm and try to
> select something, bam, your xterm crashes with BadAccess.

Which means that people would typically note quite quickly that they
need to open up things more (if they want to continue).

In my opinion this is much less worse, than having the current default,
where people who may be at risk wouldn't notice anything.


> Now, I didn't do very exhaustive testing or anything, but to
> me,
> those ten years haven't actually made a perceptible difference to how 
> X
> clients respond to failures from the SECURITY extension.

But just because clients are broken (in that respect) doesn't justify
to "work around" their issues, by making things in ssh less secure.


> So: I don't think that this decision is realistically just up to me. 
> If
> I change ssh back to use ForwardX11Trusted=no by default, a bunch of
> other maintainers are going to be asked to fix their software in 
> various
> ways: the SECURITY extension may say no to something, but you might
> reasonably expect that double-clicking in your terminal won't make it
> explode in your face. 

Fixing all clients is probably unrealistic,... but anyway, the choice
should be in the hands of the sysadmin. X forwarding is probably anyway
a rather insecure thing (whether ForwardX11Trusted is yes or no). IMHO
it should generally not be enabled per default.

Having ForwardX11Trusted=no may be enough for many clients people would
use (e.g. such which just display stuff?),... and it's the secure and
expected default for those that read the manpage (but not necessarily
the Debian-modified manpage).


Cheers,
Chris.

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

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

From: Colin Watson <cjwatson@debian.org>

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

Cc: debian-devel@lists.debian.org, debian-x@lists.debian.org

Subject: Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Wed, 19 Aug 2015 23:46:54 +0100

On Wed, Aug 19, 2015 at 11:51:36PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2015-08-19 at 20:59 +0100, Colin Watson wrote:
> > Run xterm and try to select something, bam, your xterm crashes with
> > BadAccess.
> 
> Which means that people would typically note quite quickly that they
> need to open up things more (if they want to continue).
> 
> In my opinion this is much less worse, than having the current default,
> where people who may be at risk wouldn't notice anything.

So the result is that each user of X11 forwarding swears at their
computer for a while until they work out what the problem is, and then
configure "ForwardX11Trusted no" so that it goes away.  I hardly see
this as a net improvement in the state of the world.

I would welcome comments from people other than Christoph, whose views I
am already quite familiar with.  (And thanks, Josselin.)

-- 
Colin Watson                                       [cjwatson@debian.org]

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

From: Russ Allbery <rra@debian.org>

To: Philip Hands <phil@hands.com>

Cc: 765632@bugs.debian.org, Christoph Anton Mitterer <calestyo@scientia.net>, debian-devel@lists.debian.org, debian-x@lists.debian.org

Subject: Re: Bug#765632: ForwardX11Trusted set to yes over a decade ago, for release reasons?

Date: Wed, 19 Aug 2015 16:14:35 -0700

Colin Watson <cjwatson@debian.org> writes:

> I tried some experiments with ForwardX11Trusted=no today, and frankly,
> it doesn't even pass the laugh test for usability.  Run xterm and try to
> select something, bam, your xterm crashes with BadAccess.  Now, sure,
> that's telling me that the X SECURITY extension forbids writing to the
> selection, but giving client software a chance to catch up with the
> expectation that it should handle such errors is exactly the kind of
> reason that I chose to deviate from the upstream default in the first
> place!  Now, I didn't do very exhaustive testing or anything, but to me,
> those ten years haven't actually made a perceptible difference to how X
> clients respond to failures from the SECURITY extension.

> If I thought that this was actually useful, it might be worth the pain.
> But at least I'm not the only one who thinks that this is a dubious
> benefit for the pain it brings:

>   https://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html

> So: I don't think that this decision is realistically just up to me.  If
> I change ssh back to use ForwardX11Trusted=no by default, a bunch of
> other maintainers are going to be asked to fix their software in various
> ways: the SECURITY extension may say no to something, but you might
> reasonably expect that double-clicking in your terminal won't make it
> explode in your face.

Yeah, I think I agree.

It would be great if X supported two different types of X forwarding:
trusted and untrusted, with apps working in untrusted mode but with more
restricted privileges.  Should that ever become the case, that would be a
great feature to enable.

However, right now, there are two different types of X forwarding: the one
that works, and the one that causes X apps to crash randomly.  Or, in
other words, "doesn't work."  If you want X forwarding that doesn't
actually work, just don't use the -X or -Y option at all, and you'll have
a much better error message.

If someone felt excited about doing the work required to make this feature
usable, it sounds like there's lots of low-hanging fruit in the form of X
programs that could be taught to support the X11 SECURITY extension.

In the meantime, everyone uses ssh -X to forward an X connection that will
actually work, and has adjusted to the fact that this grants a lot of
power to the remote system.  (I've been hearing warnings about being very
careful with what hosts you use -X with for something like 15 years.  It's
not old news.)  I've rarely met someone who even knew -Y existed, let
alone used it.

If there were a real feature benefit, the backwards-incompatibility may be
worth it, but given that the feature doesn't actually work, meh.  It's
hard to get particularly excited about doing work to try to enable it, and
it feels really dubious to do it by breaking the command-line option
everyone is used to using.

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

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

From: Mark Hedges <mark.hedges.data@gmail.com>

To: 765632@bugs.debian.org

Subject: option -Y should DWIM regardless of consequences

Date: Thu, 29 Oct 2015 14:08:40 -0700

Debian ought to release ssh to DWIM according to the manual.

Hiding the implicit -Y option with -X only perpetuates the security
risk in the community.

Changing the default to "ForwardX11Trusted no" will force people to
use -Y and be aware they are exposing their local X to risks from
compromised software on the remote host.

This will also provide impetus for developers of common utilities and
other distros to fix their software so it does not require a trusted
connection.  Like, why should I need a trusted connection to run
`gvim` through ssh?  It should only have to access information on the
remote side, and should only be allowed to use X drawing controls on
the local side.

The main point, is that implementing defaults so -X and -Y DWIM
according to the manual will make people aware of the security risk
they take when they use ForwardX11Trusted.

It is the Debian community's responsibility not to hide security risks
from its users.

Removing the ForwardX11Trusted default will be painful medicine, but
it is medicine the kiddies have to take, for their own good.

--
Mark Hedges, software engineer
Business info:  http://formdata.biz/

Send a report that this bug log contains spam.