Bugzilla – Bug 647633
OpenSSH X11 forwarding to untrusted multi-user systems
Last modified: 2022-01-13 16:02:54 UTC
Via vendor-sec: Hi teams, we received the following report about an issue with OpenSSH X11 forwarding. Please keep Timo Cc:ed on discussions. Our analysis indicates that the underlying problem is that there is no mutual authentication between X client and server. If we really want to address this issue, I think we need some level of UNIX domain socket support in OpenSSH (see the second message) and the ability to specify a path in the DISPLAY variable (third message; there should be a constraint on the structure of the file name, though, to avoid being able to connect to existing sockets). To be honest, I'm not quite sure if this issue is significant enough to warrant a coordinated cross-code-base attempt at preparation of a fix. Don't get me wrong: this is a real bug, but preparing updates quietly will be a real challenge due to different code bases involved. Florian From: Timo Juhani Lindfors <timo.lindfors@iki.fi> Subject: ssh: X clients can be hijacked if connection is terminated To: security@debian.org Date: Thu, 23 Sep 2010 16:47:03 +0300 Message-ID: <84y6asy3l4.fsf@sauna.l.org> Hi, here's an ssh issue I discovered today, I think it has security implications. It is a variant of #463011 (CVE-2008-1483) that I reported two years ago but can not be worked around as easily. Since with #463011 Theo complained that the bug was not reported via proper channels I'm not reporting this to the BTS yet but waiting for your instructions on how to proceed. Please reply and acknowledge when you have received this information. === bug report begins here === Steps to reproduce: 1) Mallory runs "vnc4server :3" on his local computer 2) Mallory runs "DISPLAY=:3 xhost +" on his local computer 3) Alice runs "ssh -X multiuser.example.com gnome-terminal" on her local computer 4) Alice hits ctrl-c since she realizes she wanted to start xterm instead 5) Mallory runs "ssh -R6010:localhost:6003 multiuser.example.com" on his local computer Expected results: 5) gnome-terminal dies gracefully Actual results: 5) gnome-terminal connects to Mallory's vnc4server. Mallory can type commands as Alice by using "xvnc4viewer localhost:3" on his local computer. More info: 1) The above relies on the slow startup of gnome-terminal. For testing purposes you can reproduce the problem reliably using ssh -X multiuser.example.com sh -c "'echo \$DISPLAY; read dummy; sleep 10; gnome-terminal'" in step 3. You can then write down the $DISPLAY for use in step 5 (instead of the default :10) and hit enter + ctrl-c only when you are reading to execute 6 in 10 seconds. 2) This is somewhat related to CVE-2008-1483. From: Timo Juhani Lindfors <timo.lindfors@iki.fi> Subject: Re: ssh: X clients can be hijacked if connection is terminated Date: Sat, 16 Oct 2010 20:58:55 +0300 Message-ID: <8462x2589s.fsf@sauna.l.org> Florian Weimer <fw@deneb.enyo.de> writes: > I suppose It's unfixable without help from the X11 implementation. I am not sure but I think it can be fixed by applying the patch that adds support for unix socket forwarding from http://www.25thandclement.com/~william/projects/streamlocal.html and having X clients connect to unix sockets that only the the right owner can use instead of using tcp/ip ports where such schemes are not possible unless you start configuring separate network namespaces for each user. > One way to fix this is to update the DISPLAY variable so that it can > refer to a broader range of UNIX domain sockets. What do you mean by broader range of unix domain sockets? Currently DISPLAY refers to tcp/ip port, right? From: Timo Juhani Lindfors <timo.lindfors@iki.fi> Subject: Re: ssh: X clients can be hijacked if connection is terminated Date: Sat, 16 Oct 2010 23:56:20 +0300 Message-ID: <84zkud5023.fsf@sauna.l.org> Florian Weimer <fw@deneb.enyo.de> writes: > It also refers to UNIX Domain sockets, using the ":0.0" syntax. I > don't think you can put the path to the socket there, and without > that, UNIX Domain forwarding will never be completely effective. That is true with current syntax yes. However, thanks to the modularity of Xorg it is no longer hard to add new syntax. If I modify libxcb with diff --git a/src/xcb_util.c b/src/xcb_util.c index 996ff25..fb0cd3d 100644 --- a/src/xcb_util.c +++ b/src/xcb_util.c @@ -139,6 +139,12 @@ static int _xcb_open(char *host, char *protocol, const int display) char file[sizeof(base) + 20]; int filelen; + if(protocol && strcmp("unix-with-path", protocol) == 0) + { + /* display specifices Unix socket with explicit path */ + return _xcb_open_unix("unix", host); + } + if(*host) { #ifdef DNETCONN I can use DISPLAY=unix-with-path/mysocket:10 xclock to instruct xclock to connect to the file "mysocket" as proven by strace: ... socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3 connect(3, {sa_family=AF_FILE, path="mysocket"}, 110) = 0 getpeername(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X10"}, [21]) = 0 uname({sys="Linux", node="lindi1", ...}) = 0 access("/home/lindi/.Xauthority", R_OK) = 0 open("/home/lindi/.Xauthority", O_RDONLY) = 4 ... (With this naive implementation you can't use "/" or "." in the path but that is easy to fix if we decide to take this route.)
Well, but what are we supposed to do with it? We cannot really maintain that huge separate patch. Even porting for all our products would be very time consuming. And I'll bet we would end up with more security bugs than in the beginning after some time. Personally I think that we should wait for upstream (and even then, fixing the bug for old products would be pretty risky business). What do you think?
We'll see what upstream is doing. I guess it would be fine to take upstream patches and taking care to have it packaged for our next distributions.
For what it's worth, support for UNIX domain sockets was added in openssh 6.7. (https://www.openssh.com/txt/release-6.7)