Security issues

[dxr]

Hi,

I am testing ispconfig3 for to decide if it's good solution for my servers.

I see some security problems:

1. No limits resources per client (/etc/security/limits.conf). But is not critical because i can add "a check" if new client is added for create new limit config in crontab.

2. Bad permissions:

debian5:/var/www/clients# ls -lah
total 20K
drwxr-xr-x 5 root root 4.0K 2009-06-23 12:31 .
drwxr-xr-x 7 root root 4.0K 2009-06-24 01:12 ..
drwxr-xr-x 3 root root 4.0K 2009-06-23 12:09 client1
drwxr-xr-x 3 root root 4.0K 2009-06-23 12:25 client2
drwxr-xr-x 3 root root 4.0K 2009-06-23 12:31 client3
debian5:/var/www/clients# ls -lah client3/
total 12K
drwxr-xr-x 3 root root 4.0K 2009-06-23 12:31 .
drwxr-xr-x 5 root root 4.0K 2009-06-23 12:31 ..
lrwxrwxrwx 1 root root 30 2009-06-23 12:31 lili.com -> /var/www/clients/client3/web3/
drwxr-xr-x 14 root client3 4.0K 2009-06-23 14:06 web3
debian5:/var/www/clients#

Everybody can see all files of other clients.

Yes, if we are using mod_php we can disable functions (exec, system, shell_exec, readfile, passthru, escapeshellcmd, proc_open, posix_uname, posix_getuid, posix_geteuid, posix_getgid, getcwdi, show_source, proc_open)
But if we are using suexec, we dont have this limitation and our files aren't secure.

3. open_basedir is not implmented for mod_php option (safe_mod = On, is not useful for my)

4. We have full access to the root filesystem from php.
I tried configure chroot on suphp but i didn't have good end. i Think we can configure this enviroment:

/var/www/./var/www/<site>/./{bin,etc,lib,user,web,...}

Explain:

/var/./www/var/www/<site>/./{bin,etc,lib,user,web,...}

Root file system. We can to have apache2 + mod_chroot + suexec + mysql here

/var/www/./var/www/<site>/./{bin,etc,lib,user,web,...}

This is a root chroot system installed by... hand?, debootstrap?

/var/www/./var/www/<site>/./{bin,etc,lib,user,web,...}

It's the root fs for ssh access. Its working very good

For everything work, we must move original dirs from real fs / to chroot fs /var/www/ and after create ln. Example:

mv /usr/local/ispconfig /var/www/usr/local/ispconfig
ln -s /var/www/usr/local/ispconfig /usr/local/ispconfig

The same for apache and php

We dont need move mysql dir, but we wont use local scoket connection we must use tcp (127.0.0.1 or your real ip)

CAREFUL when you update the system!!! maybe simbolic links will be removed!

About the crontab for ispconfig user will work good i think.

I didn't test this solution because i am searching solution for point 2 and 4. They are critical for me.

Any idea for fix this problems?

Thanks

[till]

1) This file is not used by ISPConfig and not needed for ISPConfig. If you want to use it for your server, feel free to do it or write a plugin for it.
2) The permissions are firn. If you dont allow reading then the apache server will stop to deliver .html files and images etc. For secure script execution e.g. use suphp with chrooting. Also you can disallow the same functions with suphp by setting a individual php.ini file per vhost. see suphp documentation for details.
3) If you want to add this then simply add it to the vhost template.
4) This is not working for hosting servers with more then a few websites, but if you want to implement this for your server, just write a new plugin. ISPConfig is easy extendable by plugins to enable administrators to configure their enviroment individually.

[dxr]

1) any user can do a while(1){ system("foobar &"); }, and freeze the server

2) The permissions are firn. If you dont allow reading then the apache server will stop to deliver .html files and images etc. For secure script execution e.g. use suphp with chrooting. Also you can disallow the same functions with suphp by setting a individual php.ini file per vhost. see suphp documentation for details.

2) Do you think is OK i can do "cat" (or if shell functions are disables include|require) from config.php of other client?
It's a a blackhole in the server.

FOR EXAMPLE:

i checked 1and1 and i see it:

drwx---r-t 4 uXXXX ftpusers 4.0K Mar 7 2008 htdocs

hehe i dont understand why apache can read htdocs but it can. Maybe fix with suexec or similar.


3) OK

4) You can check 1and1 for example. I will try configure and post the final solution.

i will try use the same binaries for all users (save storage)

[till]

1) I dont give untrusetde users SSH access anyway. But as I said, if you need it, feel free to implement it as a plugin and I will be glad to add this to the next ISPConfig release.

2) Its not ok of course. But you can prevent this by strict php settings.
4) I dont know the settings from 1and1. Its always easier to implement something if you just have one platform, ISPConfig supports debian, ubuntu, fedora, centos and suse (plus experimental support for gentoo in svn) so everything implemented here must work with all of these distributions. So implementing something like this as a separate plugin that uses debootstrap is fine but using this as the defualt setup can be a problem.

You have to keep in mind that we have to deliver a setup with ispconfig that is secure but it has also to work for users. If you check the forum then you will find e.g. a lot of complaints because we do not set allowoverride to all and so many cms systems will not work without modifying the .htaccess file that comes with them. So if we setup a 100% secure system, it will either get unusable for the users or it will use very much resources e.g. by using a separate vm per client.

[dxr]

1) OK. i will try

2) Can you show me a example for prevent this problem only with php setting please?

- suphp's chroot is a chroot for all users no per user.
- open_basedir can be disbaled with user's php.ini

4) I understand you but NOW all installations have a very bad blackhole. With a simple LFI in any CMS, forum, blog we can see all configs/user/passwords of all clients of the server and maybe use it.

I like can help for close this bug, because i like ISPconfig and i want install in my servers.

[till]

2) No, it cant be disabled with users php.ini as users can not set their own php.ini file. Just make a copy of your php.ini file, chown it to root and make it writable for root only and then specify it with

4) You can not see the files of other users if php correctly configured. Also every user can remove the world readable flag from sensible php files. But the world readable setting can not be removed from directories or htnl and image files as apache will not serve the file then.

[dxr]

4) You can not see the files of other users if php correctly configured.

how? (using suphp with exec() enabled)

[till]

Enabling exec is a security risk and exec is not needed by any common cms system, thats why you should idsable it in the custom php.ini. Same for things like passthru, popen etc.

For custom php.ini, see:

http://www.suphp.org/DocumentationVi...=apache/CONFIG

[dxr]

aha. my clients need it for bank transaction for example. Some banks provides a binary and must exec with ./binary arg1 arg2 arg3...

And if i disable exec function i can use Include and/or require for read files of other clients.

Some solution?

[till]

And if i disable exec function i can use Include and/or require for read files of other clients.

No, you cant as you had set open_basedir in the custom php.ini which restrict the access to the web directory of this specific client.