[X2go-dev] X2go is insecure

Alexander Wuerstlein snalwuer at cip.informatik.uni-erlangen.de
Tue Mar 29 16:55:50 CEST 2011


On 11-03-29 15:36, Dick Kniep <dick.kniep at lindix.nl> wrote:
> 
> Hi list,
> 
> The problem is caused by the fact that the x2go server does not
> restrict the commands that can be entered thru ssh. This is bad, but
> what is worse, is that the X2go clients actually use this security
> hole to start any command it needs.

An authorized user running commands over ssh is not a security problem
at all. It works as intended. ssh provides shells.

> To make it secure, ssh should be configured to allow only a single
> command. This wrapper-command effectively checks server side whether a
> requested command is allowed and started by the proper user. Only if
> both criteria are met, the command can be executed.
> 
> So in the configuration of the x2gossh daemon, the following line is
> added:
> 
> ForceCommand="x2gowrapper.sh $SSH_ORIGINAL_COMMAND" ssh-rsa 
>
> The $SSH_ORIGINAL_COMMAND contains the original command that the
> client wants to execute on the server. This command is checked against
> the allowed commands for the user within the wrapper.

>From the invocation I infer, that the intended language for the
wrapper is shellskript. This is extremely dangerous if intended as a
security measure like you claim. Also please note that it is very hard
to write such wrappers in a secure way, such that stuff like e.g.
'allowed_command foo bar ; evil_command' is not possible.

> Currently we are developing this wrapper that checks whether a command
> is allowed. When this is ready, we will make this available to the
> X2go project. However, acceptance of this solution will only happen if
> the principle problem is recognized.
> 
> In pyhoca-gui a distinction can be made between an x2go system user
> and the end-user that is running the application. This is a good
> start, but does not solve the problem mentioned above. However if
> combined with the wrapper it is a real secure solution, as in the
> wrapper, the system user can only execute a number of x2go commands,
> while the end-user can only execute another set of commands.

Providing some 'nx' user which can 'su' to any user on the system is one
of the worst design mistakes NX made and has extremely worrying security
implications. But it is possible that I misunderstood your intentions.

> Therefore the following changes are requested:
> 
> 1. A 	seperate instance of the ssh daemon for x2go.	

What problem should this solve? What would this sshd instance do that the
'normal' one doesn't?

> 2. A 	wrapper that is ALWAYS called when connecting to the server by the 	ssh configuration	
> 
> 3. Separate 	users for the x2go system calls and the end-user	

Again, why? What do you mean by system calls? What would be the
connection sequence in your scenario?

> 4. A 	change to the x2go clients to accomodate this change	
> 
> 5.An 	api on the server to request the allowed commands 	
> 
> 6. Automatic 	generation of the configuration on the cliënt side.

These points are valid, should however be discussed in a larger context:
Various possible future extensions require interaction between server
and client at session startup. E.g. when (hypothetically) doing
loadbalancing, the server would send load data or redirects to the
connecting client. Therefore a general API for such communications would
be useful as well as versioning within that API to provide meaningful
feedback when connecting with an 'old' client, or even to support
interaction between different client and server versions.




Ciao,

Alexander Wuerstlein.



More information about the x2go-dev mailing list