Bug 647633 - OpenSSH X11 forwarding to untrusted multi-user systems
OpenSSH X11 forwarding to untrusted multi-user systems
Status: CONFIRMED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: General
unspecified
Other Other
: P4 - Low : Normal
: ---
Assigned To: Hans Petter Jansson
E-mail List
maint:planned:update
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-19 08:16 UTC by Sebastian Krahmer
Modified: 2022-01-13 16:02 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Krahmer 2010-10-19 08:16:30 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.)
Comment 1 Anna Maresova 2010-10-19 11:53:20 UTC
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?
Comment 2 Sebastian Krahmer 2010-10-19 12:29:49 UTC
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.
Comment 5 Vítězslav Čížek 2018-11-08 09:55:53 UTC
For what it's worth, support for UNIX domain sockets was added in openssh 6.7. (https://www.openssh.com/txt/release-6.7)