[X2go-dev] x2go security Issues

[Alexander Wuerstlein]

On 11-01-20 14:48, Alexander Wuerstlein <snalwuer at cip.informatik.uni-erlangen.de> wrote:
> 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,
> > > 
> > > 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.
> > 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.
> 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.

Forget that, /usr/bin/x2gopgwrapper is of course trivially exploitable
to get root in 2 ways:
- in the current git version, set 'startshadowagent' as the first
  parameter. Choose the 11th parameter in a way such that SHADOW_USER is
  set to 'root'. Set the second parameter ($CLIENT) to something like
  'foo ; rm -fr /'. Profit.
- in the git as well as the stable version, when the database is sqlite:
  the x2gopgwrapper_sqlite runs as root meaning that any sql injection
  into sqlite would run as root. One possible injection would set the
  sqlite output file to /etc/shadow (via .output /etc/shadow) and
  overwrite it with a customized version including a new root password
  chosen by the attacker. Profit.




Ciao,

Alexander Wuerstlein.