X2Go Bug report logs - #258
SECURITY: x2goclient allows clipboard sniffing

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#258: [X2Go-Dev] Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing
Reply-To: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org
Resent-From: Christoph Anton Mitterer <calestyo@scientia.net>
Resent-To: x2go-dev@lists.berlios.de
Resent-CC: X2Go Developers <x2go-dev@lists.berlios.de>
X-Loop: owner@bugs.x2go.org
Resent-Date: Tue, 02 Jul 2013 01:33:01 +0000
Resent-Message-ID: <handler.258.B258.137272847716753@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: followup 258
X-X2Go-PR-Package: x2goclient
X-X2Go-PR-Keywords: security
Received: via spool by 258-submit@bugs.x2go.org id=B258.137272847716753
          (code B ref 258); Tue, 02 Jul 2013 01:33:01 +0000
Received: (at 258) by bugs.x2go.org; 2 Jul 2013 01:27:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.2
Received: from mailgw02.dd24.net (mailgw02.dd24.net [193.46.215.43])
	by ymir (Postfix) with ESMTPS id 1E7B15DA79
	for <258@bugs.x2go.org>; Tue,  2 Jul 2013 03:27:57 +0200 (CEST)
Received: from localhost (amavis02.dd24.net [192.168.1.113])
	by mailgw02.dd24.net (Postfix) with ESMTP id E6F213567BF
	for <258@bugs.x2go.org>; Tue,  2 Jul 2013 01:27:56 +0000 (GMT)
X-Virus-Scanned: domaindiscount24.com mail filter gateway
Received: from mailgw02.dd24.net ([192.168.1.197])
	by localhost (amavis02.dd24.net [192.168.1.106]) (amavisd-new, port 10197)
	with ESMTP id Xv3AMpvAaOfy for <258@bugs.x2go.org>;
	Tue,  2 Jul 2013 01:27:50 +0000 (GMT)
Received: from [192.168.0.101] (ppp-188-174-36-44.dynamic.mnet-online.de [188.174.36.44])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mailgw02.dd24.net (Postfix) with ESMTPSA id 8CB413566D8
	for <258@bugs.x2go.org>; Tue,  2 Jul 2013 01:27:50 +0000 (GMT)
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 258@bugs.x2go.org
In-Reply-To: <20130701140132.GQ2447@cip.informatik.uni-erlangen.de>
References: <1372646308.18508.2.camel@heisenberg.scientia.net>
	 <20130701114356.GP2447@cip.informatik.uni-erlangen.de>
	 <1372682609.25918.14.camel@heisenberg.scientia.net>
	 <20130701140132.GQ2447@cip.informatik.uni-erlangen.de>
Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-UBc+OwvjF5O1EeNaUDsf"
Date: Tue, 02 Jul 2013 03:27:49 +0200
Message-ID: <1372728469.11367.26.camel@fermat.scientia.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 

[Message part 1 (text/plain, inline)]

Hey Alexander.

First,... I assume you're one of the NX/X2go developers?


On Mon, 2013-07-01 at 16:01 +0200, Alexander Wuerstlein wrote:
> It isn't like that at all, X11 clients and servers have to comply with
> the respective parts of the protocol. If the protocol demands insecure
> behaviour, its a design bug, or maybe, like in this case, a compromise
> nobody likes: Since in X11 clients handle all the shortcuts and mouse
> button events, since clients or toolkits handle the widgets, the only
> option to implement C&P is to have clients ask the server for the
> clipboard or selection contents. Its more a "there is no other way to do
> it except to make it unusable" kind of problem imho.
Well first I may have a misunderstanding about how NX works, but more on
that below:

With respect to the issue (transferring the clipboard) itself:
Don't get this in anyway offensive! But I think it's plain simple:

It may easily happen that people copy (by intention/accidentally or even
automatically by software) stuff to the clipboard which contains
sensitive information, which in turn can be anything from passwords to
my private love letters ;-)

And people don't see x2go (or VNC, or rdp) like a direct access to their
X server (as in plain X forwarding with xauth and that like).
This might be a misunderstanding... but it's how many similar such
"VNC-like" connections (i.e. a screen output into _one single_ X window)
work.
E.g. when I connect to my qemu virtual machines, I don't have to worry,
that the VM can overtake my X server,... the same for Virtualbox... and
I hope/believe for VNC/TightVNC/etc. and rdp connections (rdesktop and
friends).

This includes that users don't expect (or at least they shouldn't have
to) that such connections allow wiretapping, e.g. if such a system
supports audio forwarding... it shouldn't allow the remote side to
activate my MIC and listen to what I say/sing/etc.

The same holds true for the clipboard... at least per default it
shouldn't be ever sent to the remote side (or vice versa)... and IF one
activates it... people should be warned with big warnings what this
could mean.


That this can indeed lead to compromise showed a recent attack we've had
on one our institutes' machines, where sensitive information was caught
via an X2go connection and later on used for other attacks.


Now for the technical side... admittedly I don't know the details of how
NX interacts with X... but there must be some way to achieve blocking of
the clipboard sync.
Even if the protocol demands to send some content,... well then simply
hook in an clear it always (per default).



Now more off topic about how NX interacts with X:

I understand that NX is not like VNC, where it's more like send the
pixbuffers.... and where you obviously have not much security problems
in terms of taking over the local X server, since it's more like
displaying JPEGS (of course VNC has much other security problems).

I haven't found out what RDP actually does... but I'd assume it's rather
similar to VNC?

Now with NX I understand it's compression at the X protocol level, so
"no JPEGs being transferred"... but where do remotes X protocol go to?
Directly into the local X? Or is it taken by NX/X2go and rendered as if
NX/X2go would be an X server that is displayed in a _single_ window of
another one (i.e. like Xephyr)?


> And if you
> wouldn't trust a host with 'ssh -X', then you also shouldn't trust it
> with x2go.
Well this is _really_ serious news...
So why? I mean that's what most people expect I guess.. like when you
connect via ssh, that the remote cannot take over your local system...
(unless some serious hole would be find in the ssh client ;) )


> Just think of x2go as a variant of 'ssh -X' with image
> compression and some extras. X11 protocol firewalling is not really one
> of those extras. And since the x2goclient will always run in your local
> X session, it will always be able to read your clipboard.
So it directly goes into the local X server? Wow... that's awful... like
a security nightmare...


> In a way, yes. Afaik you can avoid certain attacks of the "I'll attach
> to the root window and get all key events" kind since windowed x2go
> sessions give you a separate root window. But I imagine there are more
> problems out there nobody thought of yet.
Who would know for sure what is expected to be possible and what not?

I mean don't take this rude... but for me this basically makes NX
unusable, since I basically only use it to connect to more or less
untrusted nodes.
If that means these can take over my X, or even more... than good
night :-/



Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

Send a report that this bug log contains spam.