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.

      Hi!

* Christoph Anton Mitterer <calestyo@scientia.net> [2014-10-16 20:47:00 CEST]:

 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.

 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

Hi Gerfried
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:

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.
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.

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.

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.

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.
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.
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).

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.

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?

Le mercredi 19 août 2015 à 20:59 +0100, Colin Watson a écrit :

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.

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.

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.

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

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.

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> writes:

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.

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.