Securing PHP when any user can upload a vulnerable script

[dboyer]

I admin a server at my school that is owned and ran by the student union. Any student can go onto the server, sign up for an account with their student ID, and post webpages. For the students its a boon, for teachers who teach webdesign classes its a boon, but for me its a pain in the butt.

The problem isn't with the students, per se. So far, I've only had a few problems, and they've been minor (people signing up for multiple accounts, posting 1 or 2 mp3s, nothing too big). However, several users have made... grave... mistakes uploading vulnerable scripts.

One user uploaded a script that allowed any internet browser to upload any file (such as another script). Some people uploaded fake ebay pages, a text file with email addresses, and a script that parsed the email addresses and sent them links to the ebay pages - phishing at its best.

The last one was an old version of phpBB that someone used to crack into the server and turn it into a DDOS bot (for a few hours, at least). It looked like a real scriptkiddie operation, and it was cleaned up, but now I'm left with making some decisions.

Quite a few users enjoy being able to use PHP on the server, so I would hate to have to turn it off... Is there any way to secure the PHP so its not such a big issue? I hate to ask such a question here (such as its my job) but I'm really a newb when it comes to the details of admining a multiuser box, and am a bit out of my league here. Is there a simple way of fixing this?

[bwkaz]

Hmm... maybe it would help to turn off register_globals?

Many of the PHP-based vulnerabilities I've seen lately can be worked around by turning register_globals off. I have it off on my own PHP installation (... which needs to be updated, actually; there aren't any PHP scripts available from outside my network, but you never can be too sure), actually.

It's not a magic fix for all badly-written PHP scripts, though. It'll only fix some kinds of errors and will only work against some kinds of attacks.

There's also a gpc_magic_quotes setting that you could perhaps turn on, but I'm not entirely sure what it does. I think it does something with SQL and quoting (to prevent SQL injection attacks), but I don't know that for sure. I have it off, because I don't have any SQL client enabled for PHP. It won't fix all problems either, although it will (again) catch a fairly large class of them.

Probably the best (as in: will catch the most stuff) way to fix this would be to have a script submission process. You'd need to either read through all the scripts that get submitted, or have somebody else do it, or split the work up, or something. So maybe it isn't worth it. (Although I would do it, if I had the ability to upload scripts to my machine.)

[serz]

Securing PHP: Step by Step (http://www.securityfocus.org/infocus/1706)

I didn't read the whole thread, but maybe that link helps you? Hope it does.

[dboyer]

Probably the best (as in: will catch the most stuff) way to fix this would be to have a script submission process. You'd need to either read through all the scripts that get submitted, or have somebody else do it, or split the work up, or something. So maybe it isn't worth it. (Although I would do it, if I had the ability to upload scripts to my machine.)

Ha. That was offered as a solution almost word-for-word. Its not a bad idea, really, but not effective. I'm only paid for 10 hours a week, and there is no way I could catch all scripts and vulnerabilities. Stuff written by students wouldn't be too bad, but stuff like phpbb would kill me. When it first came out, there was no reason to believe there were any vulnerabilities, and I would have passed it for sure.

The other options were great ideas, I'll spend some time reading and thinking... thanks guys!