Bug 1149976
| Summary: | OpenSSH client config enables ForwardX11Trusted by default for all users | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Doug Mitchell <redhat> | |
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> | |
| Status: | CLOSED WONTFIX | QA Contact: | Stanislav Zidek <szidek> | |
| Severity: | medium | Docs Contact: | Mirek Jahoda <mjahoda> | |
| Priority: | unspecified | |||
| Version: | 7.0 | CC: | cww, pvrabec, redhat, rkratky, szidek, taisfmq, thoger, tmraz | |
| Target Milestone: | rc | Keywords: | Documentation | |
| Target Release: | --- | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1351991 (view as bug list) | Environment: | ||
| Last Closed: | 2017-11-23 12:28:17 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1255275 | |||
| Bug Blocks: | 1351991 | |||
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). |
openssh-clients-6.4p1-8.el7.x86_64 The OpenSSH client package containing /usr/bin/ssh is built with a patch to the upstream default /etc/ssh/ssh_config file that adds: # If this option is set to yes then remote X11 clients will have full access # to the original X11 display. As virtually no X11 client supports the untrusted # mode correctly we set this to yes. ForwardX11Trusted yes The comment is out of date as many X11 applications run over SSH X forwarding without forcing a trusted connection. The setting is applied system-wide to all users of the SSH client and effectively disables the X11 SECURITY extension for X connections forwarded over SSH. The man page for ssh_config(5) states that the default for ForwardX11Trusted is "no" and that if his option is set to “yes”, remote X11 clients will have full access to the original X11 display. This is not the expected default behavior as documented in the ssh(1) man page: "X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information." Having this as a system-wide default causes "ssh -X" to effectively behave as "ssh -Y". If is preferable for users to have to knowingly use "ssh -Y" when applications need full access to the X server. Unnecessarily using trusted connections allows the remote system to perform privileged actions that would normally be blocked by the X11 SECURITY extension such as keyboard sniffing ("xinput list") and taking screenshots ("xwd -root") of the SSH client's full desktop.