[X2go-dev] X2go is insecure

Dick Kniep dick.kniep at lindix.nl
Tue Mar 29 15:35:32 CEST 2011


Hi list,





In the past few month, Mike has developed a very nice python client for x2go that caters to our need as a Application service provider. However during that period, we have investigated the security of X2go and it proves that X2go is an insecure product if used in a hostile environment like the Internet. 




I know many of you are wondering: But we are using ssh, how can that be insecure? Well, as many of you know, one can connect to a server with ssh with a terminal and execute commands on that server, including commands like rm -Rf * or other commands. Even if the shell is disabled, it is still possible to execute any command on the server by using 




ssh user at server  'command' 




 

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.






 

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.






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.






 

Furthermore, the client should be able to request the allowed commands for the end-user from the server and show them. If a user wants to change a profile, he/she should be allowed to choose only from the allowed commands. Also by this method it should be possible to generate the profiles automatically from the data from the server combined with some general parameters (like client-side printing and ways to connect).






 

Therefore the following changes are requested:






1. A 	seperate instance of the ssh daemon for x2go.	

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	

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.


Anyone willing to make a comment, please do so. The overall quality will only increase!






Dick Kniep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20110329/789cdaaf/attachment.html>


More information about the x2go-dev mailing list