[X2go-dev] x2go security Issues

[Alexander Wuerstlein]

On 11-01-20 11:06, Oleksandr Shneyder <oleksandr.shneyder at obviously-nice.de> wrote:
> Am 20.01.2011 10:24, schrieb Moritz Struebe:
> > Hi,
> > Morning,
> > 
> > I am testing PyHoca. One of the problems a came around is, that the
> > client checks whether I am in the x2go group - which I'm not. I also
> > noticed that some other security-checks are done in the client. I
> > believe this is dangerous, because administrators might think that these
> > are real security checks, while they can easily be circumvented. I
> > believe these check must be done server-side. That way they can also
> > easily be adjusted by administrators.
> > 
> > Besides that, one of our admins did quite a few security patches to
> > avoid x2gowrapper having to run as root. At the moment this only works
> > for Postgres. None the less I must say that I'm not happy running
> > x2gowrapper, which is easy to exploit using SQL-Injections, as root. It
> > should at least do a "sudo -u x2go" or similar. This user only needs
> > access to the database. That way worst case the db is corrupted and not
> > the whole system.
> > 
> > Cheers
> > Morty
> 
> Hello Moritz,
> 
> I can't say nothing about PyHoca, but x2goclient make those checks not.
> 
> You are quite right about pgwrapper. Changing "sudo" to "sudo -u x2go"
> is on top of our todo list and will be made in the next version of
> x2goserver. But I don't think, that it is so easy to use x2gowrapper to
> do something bad with a system. Sure, if you can show me a working
> exploit, I will put all other things I have to do on ice and concentrate
> on this problem. In all cases I'll change behavior of x2goserver very soon.

Simplest case: SQL injection to execute arbitrary commands as 'postgres'
on the database as well as on the system. Just intently look at
/usr/bin/x2gopgwrapper_local line 42 (especially the '$2'). Exploiting
this would allow you to do anything to any database on that postgres
instance (since postgres is the administrative account by default) and
possibly (depending on the local postgres configuration) to execute
arbitrary commands as user 'postgres'. For a quick glance at what you
could do, see
http://pentestmonkey.net/blog/postgres-sql-injection-cheat-sheet/

Also, in /usr/bin/x2golistsessions line 31, the perl system() function
is used together with sudo in an insecure way. I'm currently not totally
sure, how this can be used to execute arbitrary commands as root but it
surely looks very suspicious.

Suggestions for fixing those problems would at least include the
following:
- Never sudo to root, always use a less privileged user
- Never use a database as 'postgres', always create one or more less
  privileged database users. Also, use the permissions system of the
  database and stored procedures to limit the amount of damage those
  database users can do. In the case of x2go, that would mean at least 2
  database users, e.g. 'x2go' for the unprivileged (select) database
  accesses and 'x2go_adm' for all '_root' accesses or writing.
- Always use prepared statements for database access. Since this is not
  really possible in bash, e.g. perl DBI should be used for everything
  accessing the database. This would remove the need for all those ugly
  skripts like x2golistsessions which just filter the output of psql to
  remove spaces and stuff[1].
- Never use backticks or the 'evil' one-argument form of system().




Ciao,

Alexander Wuerstlein.


[1] btw, psql has parameters -A and -F