On 11-01-20 11:06, Oleksandr Shneyder <oleksandr.shneyder@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:
Ciao,
Alexander Wuerstlein.
[1] btw, psql has parameters -A and -F