On May 3, 2007, at 2:28 AM, Jure Pečar wrote:
The most paranoid apache setup I've seen was chrooted apache with
mod_ruid taking user's uid/gid on per vhost basis. As fubar as it
looks, it mostly works.
I just looked at mod_ruid's homepage. It's the worst security
"enhancement" I've ever seen. I quote from the webpage:
-it has better performance than mod_suid2 because it doesn`t
need to kill httpd children
after one request. it makes use of kernel capabilites and after
receiving a new request suids again.
-there are some security issues, for instance if attacker
successfully exploits the httpd process,
he can set effective capabilities and setuid to root. i
recommend to use some security patch in kernel (grsec),
or something..
Like mod_suid2, it is parsing and dispatching requests as root (or
CAP_SETUID, which is basically the same thing), so another Apache
request parsing flaw would mean a root compromise. This module's
special sauce is that it is also responding to the requests with
CAP_SETUID - it is never dropping privileges! Here's my PHP-based
exploit (forgive my syntax, which is probably wrong):
# r00t and crash machine with mod_ruid and mod_php! lolz!
# <insert more stupid leetspeak here>
# <trivial "exploits" don't work unless they're filled with
stupid, arrogant, illegible comments>
# Use CAP_SYS_SETUID to get r00t!
posix_setuid(0);
# Crash the system through L1nux's "killing processes makes them
die" vulnerability!
posix_kill(1, SIGKILL);
There is no way to distinguish between mod_ruid calling setuid() and
mod_php (which runs in the same process) doing so.
In contrast, a standard Apache server setuid()s to user/group apache/
apache after binding the sockets in such a way that all special
capabilities are lost and there's no going back.
The webpage recommends mitigating its insecurity with grsec "or
something", but I don't understand how grsec can solve the
fundamentally flawed design.
The proxied Apache or FastCGI setups are *MUCH* more secure.
I guess this is the way to go if you don't want t implement some
kind of virtual machines (vps/xen/vmware).
Now that is a secure option, though not light-weight of course.
--
Scott Lamb <http://www.slamb.org/>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
