Bug 2552

Summary:	ssh -X and "ForwardX11Trusted no" break most applications, distros turn on "ForwardX11Trusted yes"
Product:	Portable OpenSSH	Reporter:	Paul Wise <pabs3>
Component:	ssh	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	enhancement	CC:	cjwatson, jjelen
Priority:	P5
Version:	7.2p1
Hardware:	All
OS:	All

Description Paul Wise 2016-03-14 13:19:42 AEDT

I'm not sure what severity this should be reported at, please adjust it if you disagree with what I chose.

"ForwardX11Trusted no" breaks most applications (including causing crashes in xterm when you select text). As a result, distributions (at least Fedora & Debian) are patching ssh -X to work like ssh -Y by turning on "ForwardX11Trusted yes". Some discussion of this issue is in this Debian thread from last year:

https://lists.debian.org/debian-devel/2015/08/msg00316.html

It seems to me that this situation is not acceptable and that something should change. The distros aren't going to budge because `ssh -X` is extremely user-unfriendly right now, so I'm hoping the OpenSSH project can help clear this logjam.

There are several possible solutions I can think of:

Fix every X11 application and toolkit to not crash when denied access. I don't think this is feasible.

Switch every X11 application and toolkit to Wayland instead. This is only slightly more feasible, since there will still be things like xterm that need a complete rewrite.

Give an error when ssh -X is used or when "ForwardX11Trusted no" is set in the configuration. This will force users to switch to learn about the choice between unstable X11 forwarding or insecure X11 forwarding, which they probably wouldn't be happy about. I don't know how the distributions would react, but it probably wouldn't be good.

For ssh -X and "ForwardX11Trusted no", implement an X11 proxy that lies to applications/toolkits about what they are allowed to do in order to prevent them from crashing. This would probably convince the distros to return to "ForwardX11Trusted no" by default. This could perhaps use xpra if it is secure enough. Otherwise this is probably going to be a lot of work to implement and test.

https://xpra.org/

Comment 1 Jakub Jelen 2016-03-14 19:33:07 AEDT

Thank you for bringing this upstream. The fact that SECURITY extension "breaks" applications is known problem for years, but when distros basically disabled untrusted forwarding, there was no reason for application developers to fix these problems. And now we are on the same page, >10 years later.

But you miss one thing that changed. The XSECURITY extension is no longer enabled by default on current systems (at least Fedora/RHEL) and disabled upstream since 2007 in favour of X Access Control Extension (XACE).

This caused CVE-2016-1908 (fallback from untrusted to trusted) when the extension is missing. Current behaviour is that untrusted X11 forwarding requests fail in this case

My initial idea was to have a look into XACE, if it is mature enough and if it would be able to work with our X11 forwarding, but Wayland/xpra look also like an interesting way to go. I would be interested in others insights on this issue.

Comment 2 Paul Wise 2016-03-15 13:09:20 AEDT

Thanks for that information. Using XACE sounds better than xpra since the latter would be an extra external dependency.

Wayland support would be an entirely separate feature and probably off-topic here. There has been some work on transporting Wayland over the network here:

https://lists.freedesktop.org/archives/wayland-devel/2016-February/026933.html
https://blogs.s-osg.org/wow-wayland-over-wire/