From unknown Sat May 16 09:06:26 2026 X-Loop: owner@bugs.x2go.org Subject: Bug#287: [X2Go-Dev] Bug#287: x2goserver allows to connect to ALL X server sessions by default Reply-To: David Fuhrmann , 287@bugs.x2go.org Resent-From: David Fuhrmann Original-Sender: david.fuhrmann@gmail.com Resent-To: x2go-dev@lists.berlios.de Resent-CC: X2Go Developers X-Loop: owner@bugs.x2go.org Resent-Date: Wed, 07 Aug 2013 12:03:01 +0000 Resent-Message-ID: Resent-Sender: owner@bugs.x2go.org X-X2Go-PR-Message: followup 287 X-X2Go-PR-Package: x2goserver X-X2Go-PR-Keywords: not-a-bug moreinfo wontfix Received: via spool by 287-submit@bugs.x2go.org id=B287.13758764566420 (code B ref 287); Wed, 07 Aug 2013 12:03:01 +0000 Received: (at 287) by bugs.x2go.org; 7 Aug 2013 11:54:16 +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=FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ymir (Postfix) with ESMTPS id 6E83B5DB1E for <287@bugs.x2go.org>; Wed, 7 Aug 2013 13:54:15 +0200 (CEST) Received: by mail-ve0-f176.google.com with SMTP id b10so1642741vea.7 for <287@bugs.x2go.org>; Wed, 07 Aug 2013 04:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HGd5TT63eS3fZeuNQKFpK3IFDtcG8RP94dPuhu+zK/8=; b=XFnZvRodbjqlJBkxOdqUvZil5sjper5NGf0tRyjJkQvxlNMpbrtmf2gD45lEKChVbP FQ3Hm8BvEE9qIPTqVNgg2Xe/oOWZkXsf9cte0mSUluLHXxCUFlGTxou1If4Ev/ofKUE7 Dparx6bUrUrM3HZxnhT8A+IYi5fwc6HtqUB6nox4rzbUCXWEOd1MZSiy8n5ztdd//e/P vAVubRyxeU79oisILg3xA70SC1u0Cb4PYR7UhrND+MbUQq7XPNpKHnByewzD8iu1Z+yF dvZY7f+BYOPx1wn0ATud9Di6M4M98fn9YaG5KZgbZdI4/ZrOk+bZ8RU07ZNeLmsLUk6U NZbA== MIME-Version: 1.0 X-Received: by 10.58.209.5 with SMTP id mi5mr94567vec.46.1375876454107; Wed, 07 Aug 2013 04:54:14 -0700 (PDT) Sender: david.fuhrmann@gmail.com Received: by 10.52.76.167 with HTTP; Wed, 7 Aug 2013 04:54:14 -0700 (PDT) In-Reply-To: <20130807114338.13215dfoanwep8sq@mail.das-netzwerkteam.de> References: <20130807114338.13215dfoanwep8sq@mail.das-netzwerkteam.de> Date: Wed, 7 Aug 2013 13:54:14 +0200 X-Google-Sender-Auth: jerFbzpIw5fSwvX40QgarkHhkaU Message-ID: From: David Fuhrmann To: Mike Gabriel Cc: 287@bugs.x2go.org Content-Type: multipart/alternative; boundary=047d7bd6bbba4d63e004e35a33fd --047d7bd6bbba4d63e004e35a33fd Content-Type: text/plain; charset=ISO-8859-1 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 > 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: mike.gabriel@das-netzwerkteam.**de, > http://das-netzwerkteam.de > > freeBusy: > https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-** > netzwerkteam.de.xfb > --047d7bd6bbba4d63e004e35a33fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 x= 2godesktopsharing.
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 lea= ve 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 conne= ct 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 t= o 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 shoul= d 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 lo= cal users.

With best regards,
David




2013/8/7 Mike Gabriel <mike.gabriel@das-ne= tzwerkteam.de>
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 mi= ght be logged in local users, or NX sessions which were not terminated corr= ectly. This is especially worse in the latter case, as the screen is not lo= cked here, normally.

This is a HUGE security leak, as now all users are able to access data of t= he other users, and hinder them from working by manipulating current sessio= ns.

Normal remote desktop software should BLOCK such access by default, and onl= y 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 (sunweave= r) 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 mistak= e 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: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/fr= eebusy/m.gabriel%40das-netzwerkteam.de.xfb

--047d7bd6bbba4d63e004e35a33fd--