X2Go Bug report logs - #509
Document NX/X11 security issue: clipboard sniffing

Package: wiki.x2go.org; Maintainer for wiki.x2go.org is x2go-dev@lists.x2go.org;

Reported by: Christoph Anton Mitterer <calestyo@scientia.net>

Date: Mon, 1 Jul 2013 02:48:02 UTC

Severity: grave

Tags: security

Full log

Message #40 received at 258@bugs.x2go.org (full text, mbox, reply):

Received: (at 258) by bugs.x2go.org; 2 Jul 2013 16:14:58 +0000
From arw@cip.cs.fau.de  Tue Jul  2 18:14:57 2013
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_BLOCKED,
	URIBL_BLOCKED autolearn=ham version=3.3.2
X-Greylist: delayed 424 seconds by postgrey-1.34 at ymir; Tue, 02 Jul 2013 18:14:57 CEST
Received: from faui03.informatik.uni-erlangen.de (faui03.informatik.uni-erlangen.de [])
	by ymir (Postfix) with ESMTPS id 9E81E5DB13
	for <258@bugs.x2go.org>; Tue,  2 Jul 2013 18:14:57 +0200 (CEST)
Received: from warp (vpn-000-018.vpn.informatik.uni-erlangen.de [])
	(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by faui03.informatik.uni-erlangen.de (Postfix) with ESMTPS id 196F1680908;
	Tue,  2 Jul 2013 18:07:53 +0200 (CEST)
Date: Tue, 2 Jul 2013 18:07:52 +0200
From: Alexander Wuerstlein <arw@cip.cs.fau.de>
To: x2go-dev@lists.berlios.de
Cc: Christoph Anton Mitterer <calestyo@scientia.net>, 258@bugs.x2go.org
Subject: Re: [X2Go-Dev] Bug#258: Bug#258: Bug#258: SECURITY: x2goclient
 allows clipboard sniffing
Message-ID: <20130702180752.6b3c8c97@warp>
In-Reply-To: <1372728469.11367.26.camel@fermat.scientia.net>
References: <1372646308.18508.2.camel@heisenberg.scientia.net>
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 02 Jul 2013 03:27:49 +0200
Christoph Anton Mitterer <calestyo@scientia.net> wrote:

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

I've submitted some patches, yes. But I don't commit things as often as I would
want to.

> 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:
> 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).

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. X11 has a far larger amount of functionality and a huge system of
extensions on top. 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.

> 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

> 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.

I agree that this would be desirable.

> 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?

> 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.

> Now more off topic about how NX interacts with X:
> [...]
> 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.

> > 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 ;) )

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

> > 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...

Yes, it can be.

> > 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 :-/

Yes, connections to untrusted hosts are problematic. For this I consider VNC to
be more suited.


Alexander Wuerstlein.

Send a report that this bug log contains spam.

X2Go Developers <owner@bugs.x2go.org>. Last modified: Wed Feb 8 10:10:58 2023; Machine Name: ymir.das-netzwerkteam.de

X2Go Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.