Subject: x2goserver allows to connect to ALL X server sessions by default

From: David Fuhrmann <[email-masked]>
Date: Wed, 7 Aug 2013 07:36:18 +0200

Package: x2goserver
Version: 4.0.1.6
Severity: critical

Hi,

I just noticed that x2goserver allows to connect to ALL running X sessions on the target machine, using "connect to local desktop". These might be logged in local users, or NX sessions which were not terminated correctly. This is especially worse in the latter case, as the screen is not locked here, normally.

This is a HUGE security leak, as now all users are able to access data of the other users, and hinder them from working by manipulating current sessions.

Normal remote desktop software should BLOCK such access by default, and only allow it when the user explicitly requested it or configured it so.

---

From: Mike Gabriel <[email-masked]>
Date: Wed, 07 Aug 2013 11:43:38 +0200

control: tag -1 moreinfo
control: tag -1 not-a-bug
control: tag -1 wontfix

On Mi 07 Aug 2013 07:36:18 CEST David Fuhrmann wrote:

> I just noticed that x2goserver allows to connect to ALL running X  
> sessions on the target machine, using "connect to local desktop".  
> These might be logged in local users, or NX sessions which were not  
> terminated correctly. This is especially worse in the latter case,  
> as the screen is not locked here, normally.
>
> This is a HUGE security leak, as now all users are able to access  
> data of the other users, and hinder them from working by  
> manipulating current sessions.
>
> Normal remote desktop software should BLOCK such access by default,  
> and only allow it when the user explicitly requested it or  
> configured it so.

I just tested this to be really sure that this is a not-a-bug report...

What you describe only works for the same login!!!! So if my user  
(sunweaver) logs in locally to an X-Session and ,,sunweaver'' then  
connects via X2Go to connect to a local X session then I can access my  
__own__ local X sessions.

However, I cannot access other users' sessions unless they grant  
access via the X2Go Desktop Sharing utility.

Please re-test and re-confirm or post a message that states that the  
mistake was on your part.

Thanks+Greets,
Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: [email-masked], http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

---

From: David Fuhrmann <[email-masked]>
Date: Wed, 7 Aug 2013 13:54:14 +0200

thanks

... for the answer. We just retested it today in our environment, and the
issue is still as described. Especially we did:

1) user_A starts a xfce x2go session on hostA, without starting
x2godesktopsharing.
2) user_B logs in at hostA, using "connect to local desktop. It sees a X
session under its own user name, and a port. user_B can click on "full
access" and gets access to the session.

Second test:
- user_A starts x2godesktopsharing, but leave the default setting (do not
allow access, with cross).
- user_B sees same behaviour as described above

Third test:
- user_A starts x2godesktopsharing, but and enables access (green icon in
menu bar)
- user_B now sees two sessions in the session list: one with his own user
name, one with user_As user name. Both have the same port. If user_B
selects the one which has user_A as its name, he can only connect to view,
and eventually, this connection gets refused. (In the mean time, user_A
sees a question dialog asking user_B for access in the session.)
But still, user_B sees a session with his own name, and can connect to it
and gets full access to the xfce session started by user_A.

So in summary: The x2godesktopsharing has no effect at all when it should
block all accesses, and only works partly when it should allow individual
access.

In our environment, every machine has the same logins provided by an LDAP
server. I will retest at home to see how it behaves with normal local users.

With best regards,
David

2013/8/7 Mike Gabriel <[email-masked]>

>> sessions on the target machine, using "connect to local desktop". These
>> might be logged in local users, or NX sessions which were not terminated
>> correctly. This is especially worse in the latter case, as the screen is
>> not locked here, normally.
>>
>> This is a HUGE security leak, as now all users are able to access data of
>> the other users, and hinder them from working by manipulating current
>> sessions.
>>
>> Normal remote desktop software should BLOCK such access by default, and
>> only allow it when the user explicitly requested it or configured it so.
>>
>
> (sunweaver) logs in locally to an X-Session and ,,sunweaver'' then connects
> via X2Go to connect to a local X session then I can access my __own__ local
> X sessions.
>
> However, I cannot access other users' sessions unless they grant access
> via the X2Go Desktop Sharing utility.
>
> mail: mike.gabriel@das-netzwerkteam.**de<[email-masked]>,
> http://das-netzwerkteam.de
>
> freeBusy:
> https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-**
> netzwerkteam.de.xfb<https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb>
>

---

From: Mike Gabriel <[email-masked]>
Date: Wed, 07 Aug 2013 16:02:58 +0200

control: tag -1 - wontfix
control: tag -1 - not-a-bug

Hi David,

> server. I will retest at home to see how it behaves with normal local users.

Ok, thanks for re-testing. I undo the taggings earlier made on this  
issue. This is indeed a big issue that needs immediate fixing!!!

Next question: what distro are you on. I tested on Debian and it  
worked flawlessly. Do you have any chance to test on Debian or Ubuntu  
(if you are on some RPM based distro)?

Greets,
Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: David Fuhrmann <[email-masked]>
Date: Wed, 7 Aug 2013 17:56:45 +0200

Hi,

We are using a debian-based linux mint, and installed the server from the debian 7 repository IIRC.

I just tested at home on Ubuntu 10.04, and here it works fine. I think this might be some configuration issue.

Best,
David

Am 07.08.2013 um 16:02 schrieb Mike Gabriel <[email-masked]>:

> Ok, thanks for re-testing. I undo the taggings earlier made on this issue. This is indeed a big issue that needs immediate fixing!!!
> 
> Next question: what distro are you on. I tested on Debian and it worked flawlessly. Do you have any chance to test on Debian or Ubuntu (if you are on some RPM based distro)?
> 
> Greets,
> Mike
> 
> 
> -- 
> 
> DAS-NETZWERKTEAM

---

From: David Fuhrmann <[email-masked]>
Date: Wed, 7 Aug 2013 20:10:44 +0200

Hi,

To rule out some specific configuration issue in our current system, I installed a fresh linux mint inside a virtual machine and was able to confirm the issues.

You should be able to reproduce it easily by doing the same. Choose Linux Mint debian edition, 64 Bit, Mate package and install x2goserver following your instructions for debian 7.

With best regards,
David

---

From: Mike Gabriel <[email-masked]>
Date: Wed, 07 Aug 2013 21:22:25 +0200

Hi David,

On Mi 07 Aug 2013 20:10:44 CEST David Fuhrmann wrote:

> To rule out some specific configuration issue in our current system,  
> I installed a fresh linux mint inside a virtual machine and was able  
> to confirm the issues.
>
> You should be able to reproduce it easily by doing the same. Choose  
> Linux Mint debian edition, 64 Bit, Mate package and install  
> x2goserver following your instructions for debian 7.

What is the primary GID of users on Linux Mint. Do they follow the pattern

   foo:foo
   bar:bar
   sunweaver:sunweaver

or is there a group that all users get crushed in with there primary  
GIDs, like

   foo:users
   bar:users
   sunweaver:users

???

Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: David Fuhrmann <[email-masked]>
Date: Wed, 7 Aug 2013 21:56:19 +0200

Am 07.08.2013 um 21:22 schrieb Mike Gabriel <[email-masked]>:

> or is there a group that all users get crushed in with there primary GIDs, like
> 
>  foo:users
>  bar:users
>  sunweaver:users

In a fresh linux mint system, the first one. In our production environment, the latter one.

---

From: David Fuhrmann <[email-masked]>
Date: Sat, 17 Aug 2013 09:03:21 +0200

Any news regarding this bug?

---

From: Mike Gabriel <[email-masked]>
Date: Sat, 17 Aug 2013 17:28:16 +0200

Hi David,

> Any news regarding this bug?

I have set up a test VM for this issue today and I can absolute  
confirm what you report.

I will investigate on that further today/tomorrow, and I am quite sure  
of being able to exploit this without X2Go as well.

My guess is a mis-configuration in Linux mint around the local X-Server.

Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Stefan Baur <[email-masked]>
Date: Sat, 17 Aug 2013 17:37:29 +0200

Please look at message

From: Fred Her.  <[email-masked]>
Date: Fri, 16 Aug 2013 14:47:40 +0000 (UTC)
Message-ID: <[email-masked]>

which I just forwarded to the bugtracker (seems it went to the list, but 
not the bugtracker).

Looks like the root cause for the problem has been found and it is 
indeed a Linux Mint configuration stupidity.

-Stefan

Am 17.08.2013 17:28, schrieb Mike Gabriel:
> _______________________________________________
> X2Go-Dev mailing list
> [email-masked]
> https://lists.berlios.de/mailman/listinfo/x2go-dev