Christoph Anton Mitterer | 2 Jul 19:47 2013

Bug#258: Bug#258: Bug#258: Bug#258: SECURITY: x2goclient allows clipboard sniffing

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.

>  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

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

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.



Attachment (smime.p7s): application/x-pkcs7-signature, 6980 bytes
X2Go-Dev mailing list
X2Go-Dev <at>