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:
- 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