Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : Apache Nobody Security Hole

[Alex042]

I think I may have briefly touched on this issue before, but have now found what I was looking for in a brief investigation. One of the things that pushed this investigation was this issue: http://www.webhostingtalk.com/showth...ght=mysql+sock that just affected one of the servers I'm hosted on. Evidentially Apache had removed the required mysql file or more precisely 'nobody' removed the file so no php/mysql page would load and my sites were dead in the water. Fortunately the answer was here on WHT to fix the this issue and my host had given me the necessary rights so I was able to fix the immediate issue and my host followed up on that to secure it.

After some brief testing and some quick code writing following this incident, what I've found is that with 1 line of code, a php script running as nobody can assume whatever rights nobody has so if nobody has rights to remove a file then so can the person running the php script. I was able to create this 1 liner in a matter of seconds. Hosts need to be aware, if not already, that this may be an issue. One possible solution we're testing is chowning some files to root so nobody doesn't have access to change them.

It gets really frustrating when my sites go down because of issues like this so hopefully this fix will be somewhat permanent and we don't have to go through it again.

We already have SUEXEC installed which seems to work ok but I hate to have to recommend PHPEXEC when it seems to have some incompatibilities.

[sigma]

Originally posted by Alex042
I think I may have briefly touched on this issue before, but have now found what I was looking for in a brief investigation. One of the things that pushed this investigation was this issue: http://www.webhostingtalk.com/showth...ght=mysql+sock that just affected one of the servers I'm hosted on. Evidentially Apache had removed the required mysql file or more precisely 'nobody' removed the file so no php/mysql page would load and my sites were dead in the water. Fortunately the answer was here on WHT to fix the this issue and my host had given me the necessary rights so I was able to fix the immediate issue and my host followed up on that to secure it.

After some brief testing and some quick code writing following this incident, what I've found is that with 1 line of code, a php script running as nobody can assume whatever rights nobody has so if nobody has rights to remove a file then so can the person running the php script. I was able to create this 1 liner in a matter of seconds. Hosts need to be aware, if not already, that this may be an issue. One possible solution we're testing is chowning some files to root so nobody doesn't have access to change them.

Lots of hosts pretend that user-written scripts can't access anything on the server that Apache can. Hosts don't like to talk about it. Clients don't understand it. It's the elephant in the living room.

Having said that, why do you think user nobody was able to remove /tmp/mysql.sock? If /tmp is chmod 1777 and mysql.sock was a symlink made by root, that wouldn't be possible. Certainly it's a bad idea to have *anything* critical to the system be owned by nobody.

Kevin

[i am a]

agreed, it's a known problem (php as nobody) but it can be mitigated with some careful thinking of who owns what.

but yes, definitely no excuse to run the tmp directory without a sticky bit, or to launch mysql as "nobody"

[Alex042]

Having said that, why do you think user nobody was able to remove /tmp/mysql.sock? If /tmp is chmod 1777 and mysql.sock was a symlink made by root, that wouldn't be possible. Certainly it's a bad idea to have *anything* critical to the system be owned by nobody.

I'm not sure why it was owned by nobody but in the reply from my host after it was replaced, he stated that the logs showed it was owned by nobody and that nobody had removed it.

[mpope]

yep, this is a problem with php and nobody owning it... I mean the whole point of the user "nobody" is to allow anyone access to a certain set of scripts which should be non-vital anyway (this could probably be debated )

Anyway... mysql.sock shouldn't be owned by nobody... that's pretty much just completely negligent...

[magnafix]

<troll>
mod_php should not be run on a shared system.
</troll>



Seriously though, this is not so much a problem of PHP, but of offering server-side scripting on a shared system, at all... unless you can do chrooted CGI. Numerous threads have debated this topic on WHT over the past year or two.

[chirpy]

<quote>unless you can do chrooted CGI</quote>

Which can give you a false sense of security, it's in no way infallible.

The only realsitic solution in a shared environment is to use SuExec, PHPExec and setup correct *nix file and directory permissions.