X2Go Bug report logs - #506
Globally allow server-side disabling of the clipboard

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#258: [X2Go-Dev] Bug#258: 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 17:48:02 +0000
Resent-Message-ID: <handler.258.B258.13727872552165@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.13727872552165
          (code B ref 258); Tue, 02 Jul 2013 17:48:02 +0000
Received: (at 258) by bugs.x2go.org; 2 Jul 2013 17:47:35 +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 mailgw01.dd24.net (mailgw01.dd24.net [193.46.215.41])
	by ymir (Postfix) with ESMTPS id 0C9F55DB13
	for <258@bugs.x2go.org>; Tue,  2 Jul 2013 19:47:35 +0200 (CEST)
Received: from localhost (amavis01.dd24.net [192.168.1.111])
	by mailgw01.dd24.net (Postfix) with ESMTP id CFBD17CC1DA;
	Tue,  2 Jul 2013 17:47:34 +0000 (GMT)
X-Virus-Scanned: domaindiscount24.com mail filter gateway
Received: from mailgw01.dd24.net ([192.168.1.191])
	by localhost (amavis01.dd24.net [192.168.1.105]) (amavisd-new, port 10191)
	with ESMTP id EEZUKWs1mR3y; Tue,  2 Jul 2013 17:47:28 +0000 (GMT)
Received: from [10.153.238.27] (unknown [141.84.43.125])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by mailgw01.dd24.net (Postfix) with ESMTPSA id 5936B7CC1C5;
	Tue,  2 Jul 2013 17:47:28 +0000 (GMT)
Message-ID: <1372787237.7849.101.camel@heisenberg.scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 258@bugs.x2go.org
Cc: x2go-dev@lists.berlios.de
Date: Tue, 02 Jul 2013 19:47:17 +0200
In-Reply-To: <20130702180752.6b3c8c97@warp>
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>
	 <1372728469.11367.26.camel@fermat.scientia.net>
	 <20130702180752.6b3c8c97@warp>
Content-Type: multipart/signed; micalg="sha512";
	protocol="application/x-pkcs7-signature";
	boundary="=-biy9qWMbz3n7guFJvWCa"
X-Mailer: Evolution 3.4.4-3 
Mime-Version: 1.0

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

On Tue, 2013-07-02 at 18:07 +0200, Alexander Wuerstlein wrote: 
> Well, in that aspect, VNC, RDP and x2go/NX are somewhat different. VNC and RDP
> basically started from some dumb kind of framebuffer and keyboard/mouse event
> forwarding.
I knew (at least the VNC / RDP part)... and I started to realise the
difference from NX ;)

> X11 has a far larger amount of functionality and a huge system of
> extensions on top.
Sure...

>  x2go/NX starts out from X11 and changes some aspects,
> pruning things that are slow or unnecessary (e.g. synchronous calls or
> uncompressed bitmaps). So while with VNC/RDP you have a very simple starting
> point from which you then can add some extensions like clipboards, with
> X11/x2go/NX you have everything and need to throw away stuff that might be bad.
> People are still in the process of figuring out the bad stuff, and generally its
> the far more hazardous direction of development.
That's the problem... at least security wise... I mean it's no wonder
that no sane person uses ssh -X on other hosts (especially untrusted
ones)... the X protocol is so complex especially with all extensions..
and the typical attacks like global event grabbing or a "screen man in
the middle attack" where a new full screen window tricks you into
something evil... are probably just the simplest ideas of attacking.


> > 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.
> Well, if you switch on audio forwarding in RDP, the other side can do exactly
> that...
Sure... but at least you can turn it of (unfortunately many programs
don't do so by default, neither do they warn you what switching it on
means.


> > 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.
> Do you have any more in-depth writeup of that attack so we maybe can learn from
> it and look at certain things more specifically?
Well the problem is that I'm not really allowed to give much defaults
(as you can see I also write from my private address)...
Simply said... an attacker took over root on the remote system... and it
seems he did just such sniffing stuff... :/


> > 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).
> 
> Yes, that should be possible. Its just that someone has to implement it.

AFAIU, one would need to do that on the nxproxy level then?


> > 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)?
> Some protocol calls are taken as is and passed to the local X, others are
> "transformed", e.g. made asynchronous, bitmap-compressed, etc.
I see...


> Well, the remote can't take over your system afaik. But there are concerns
> about the security of ssh -X vs. -Y. Keystroke monitoring is one of those
> concerns.
Why don't you do the following:
Not passing on any X stuff to the local X server... but staring an
Xephyr server and sending it there?

Admittedly I don't really know how the Xephyr server itself does things
(I once tried to ask the developers but got no reply)... and if that
would really work like a sandbox ...
At least my hope would be (as it was before with VNC/RDP/NX)... that any
evil remote... could at least only take over the one single window...
and in case of Xephyr... hopefully only the single Xephyr window.



First thanks for your answers...

I'd propose the following now:
As this bug is now cluttered all over with two different issues
- clipboard sniffing and the warning when it was activated
- security measures and better documentation about what NX/X2go really
does

I'd close this bug, and open two new ones, one for each issue...
referencing that old bug... so that all topics can be discussed (perhaps
fixed) in a more simple fashion.

Okay?


Cheers,
Chris.

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

Send a report that this bug log contains spam.