Hi Doug,
This default is in our systems for quite a long time (I can track it as far as 2006, but it is older) and back then there was priority to have things working. I understand that this can have security implications if you connect to untrusted remote (but you shouldn't do even without ForwardX11Trusted), but it would require some more investigation behind change of default in rhel-7.2.

Can you point out some source mentioning current state of X Security Extension? I found only almost 10 years old saying that is was quite working:
http://dailypackage.fedorabook.com/index.php?/archives/48-Wednesday-Why-Trusted-and-Untrusted-X11-Forwarding-with-SSH.html

I can test only around our infrastructure.

I don't see anything recent, I think insecure defaults were adopted to make it work and they were never revisited.

Original upstream docs:
http://www.x.org/wiki/Development/Documentation/Security/

Detailed paper on attacks:  (2004)
http://www.giac.org/paper/gcih/571/x11-forwarding-ssh-considered-harmful/104780

Ubuntu discussion:   (2011)
http://askubuntu.com/questions/35512/what-is-the-difference-between-ssh-y-trusted-x11-forwarding-and-ssh-x-u

I believe that the goal of the SECURITY extension is to make it more safe to connected to an untrusted remote.

Thank you for response.

On its own it is not as insecure as it was since X11Forwarding is not default. But if you start to play with -X or -Y (which in our default configuration doesn't differ) we are back where we were with CVE-2000-0217.

I just checked how does it work in current Fedora 21 and I found that Security Extension is no longer available in X server so even if I remove ForwardX11Trusted, all the X connections fall back to trusted without any restrictions (you can check xdpyinfo, there is no security extension)

It was really hard to find something about this topic, but I managed even Red Hat advisory from 2013 [1]

> In Red Hat Enterprise Linux 6, the X Security extension (XC-SECURITY) has
> been disabled and replaced by X Access Control Extension (XACE)

so it looks like the security provided by openssh should be reimplemented to follow such change, if XACE is yet operational.


[1] http://www.redhat.com/archives/rhsa-announce/2013-November/msg00028.html

(In reply to Jakub Jelen from comment #5)
> I just checked how does it work in current Fedora 21 and I found that
> Security Extension is no longer available in X server so even if I remove
> ForwardX11Trusted, all the X connections fall back to trusted without any
> restrictions

The fallback to trusted connection is because of combination of openssh bug and the default RHEL/Fedora xinit which runs: xhost +si:localuser:`id -un`

The openssh bug was fixed upstream in version 7.1p2, see bug 1298741.

Adding to Tomas comment. This was not actually fixed in 7.1p2 and got CVE-2016-1908 without upstream release so far (fix in master [1].

There is no X Security extension in RHEL 7 so removing ForwardX11Trusted would have only effect of automatic fallback to trusted (as described in comment #5) and after fixing the above mentioned CVE, it would start (correclty) failing. If the Security extension would get re-enabled, we should fix also this issue.

[1] https://anongit.mindrot.org/openssh.git/commit/?id=ed4ce82dbfa8a3a3c8ea6fa0db113c71e234416c

Are you sure that the SECURITY extension is completely removed?  With current CentOS 7.2 on both SSH client and server, there appears to be some difference between -X and -Y operation.  I can turn on/off the ability of the server to enumerate the client's hardware:

"Safe" example:

[doug@client ~]$ ssh -X server
[doug@server ~]$ xinput list 
Unable to connect to X server

"Insecure" example:

[doug@client ~]$ ssh -Y server
[doug@server ~]$ xinput list 
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Logitech G500                           	id=10	[slave  pointer  (2)]
⎜   ↳ Logitech G500                           	id=11	[slave  pointer  (2)]
⎜   ↳ Logitech Logitech Illuminated Keyboard  	id=13	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ Logitech Logitech Illuminated Keyboard  	id=12	[slave  keyboard (3)]

The server can enumerate keyboard/mouse attached to client.  Additionally with "xinput test [id]" running on the server, it can sniff keystrokes in other client windows, which is a real security problem.

I should add that the above examples are after I had taken steps to protect myself by adding these lines to my $HOME/.ssh/config file:

Host *
ForwardX11 no
ForwardX11Trusted no

-X and -Y are meant to behave differently.

-X enables X11 forwarding.  Unless you have ForwardX11Trusted yes in the config (note that it's in the default ssh_config on Red Hat Enterprise Linux and Fedora, which is what this bug is about), it only enables untrusted X11 forwarding.  Untrusted forwarding depends on SECURITY extension in the local X server.  If your X server does not have the extension, X11 forwarding should not get enabled at all.  Do you see a warning as the one below?

Warning: untrusted X11 forwarding setup failed: xauth key data not generated

Does $DISPLAY get set?

-Y enables trusted X11 forwarding.  SECURITY extension is not used, and remote X clients should have the same access to X server as local X clients.

Tomas, thanks for clearing that up.  In the case of two RHEL 7.x machines, DISPALY does not get set, so there is no X11 connection.  I now understand that RHEL 7.x SSH client does not support untrusted X11 forwarding.

This does get more complicated when you have both 6.x and 7.x boxes as both clients and servers, especially with NFS mounted home directories, which allow sharing of $HOME/.ssh/config files.

(In reply to Doug Mitchell from comment #17)
> I now understand that RHEL 7.x SSH client does not support untrusted X11
> forwarding.

This is not a limitation of SSH client, but of X server.  SSH client should be able to forward untrusted X11 connection if used with X server with SECURITY extension.

I believe all the questions were answered and there is nothing we can do in this bug any further.
The default works out of the box and the issue is documented in Security Guide [1]. Can we close this bug now?

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/Security_Guide/index.html#sec-Securing_SSH

OK, now that the X Security extension is claimed to be disabled in Section 4.3.11 of the Security Guide [1], can we re-enable it? Re-compiling the X server may work but it is not an easy job.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/Security_Guide/index.html

Closing since there is nothing to be fixed in OpenSSH and documentation is updated accordingly.

Hopefully next time we will be asking this question, we will be running some secure displays such as Wayland.

To answer last question, no X Security Extension can not be enabled at runtime, because it is build-time disabled and deprecated by Xorg years ago. Re-enabling was done in RHEL6, it was also considered for RHEL7, but it was not decided to do so (private bug #1255275).