On Fri, Sep 26, 2008 at 04:32:41PM -0500, Gunnar Wolf wrote:
> Up until now (as far as I gan tell from the behaviour, I'm not
> referring to the source for details), I think the (grossly simplified)
> startup process of Cherokee was:
>
> 1- Come to live
> 2- Open logfiles
> 3- Drop privileges
> 4- Open a socket, sit and wait for connections
>
> If I get it correctly, 0.9 has reversed 2 and 3. Why? Because up to
> now, Cherokee (as shippped in Debian) produced root-owned
> /var/log/cherokee/cherokee.{access,error}. I just packaged (didn't yet
> upload) 0.9, and... it fails to start:
>
> 0 [EMAIL PROTECTED]/home/gwolf# cherokee
> Couldn't open '/var/log/cherokee/cherokee.access' for appending
> 2 [EMAIL PROTECTED]/home/gwolf# ls -l /var/log/cherokee/cherokee.*
> -rw-r--r-- 1 root root 1143 2008-09-26 14:11 /var/log/cherokee/cherokee.access
> -rw-r--r-- 1 root root 388 2008-09-26 14:11 /var/log/cherokee/cherokee.error
IMHO, good. Reversing the order of items 2 and 3 was the right thing to
do. There is a major security issue with opening log files as root
before dropping credentials. You cover the reason below:
> Now thinking on possible scenarios: Opening the log file with root
> privileges does expose us (at a single point, though, in the program's
> life) to a symlink attack - If somebody symlinks
> /var/log/cherokee/cherokee.access to, say, /lib/libc.so.6, we can very
> easily clobber that file and render our system useless. But still, the
> attacker must already have root privileges in order to do this! (of
> course, we _are_ checking file ownership before writing, right?)
Incorrect. Take the following scenario (I do not speak Cherokee, so
this is Apache syntax), which users often want (because they want to be
able to watch their web traffic in real-time):
<VirtualHost ...>
CustomLog /home/jdc/www_logs/access.log combined
</VirtualHost>
drwx--x--x 14 jdc users 512 26 Sep 03:03 /home/jdc/
drwx------ 5 jdc users 512 26 Sep 03:03 /home/jdc/www_logs/
-rw-r--r-- 1 root wheel 5033 26 Sep 09:18
/home/jdc/www_logs/access.log
All user "jdc" has to do is:
$ cd ~/www_logs
$ rm -f access.log
$ ln -s /etc/passwd access.log
And then wait for the webserver to re-open the logfiles (such as upon
restart). Let the games begin.
Even if /home/jdc/www_logs was owned by root:wheel, this would not
solve the problem either. User "jdc" would just do:
$ rm -fr ~/www_logs
$ mkdir_~/www_logs
$ cd ~/www_logs
$ ln -s /etc/passwd access.log
I hope you see the implications here.
In case you're wondering what happens to the log data between the time
the above exploit is executed and the webserver is restarted: the
webserver will still have the file descriptor to the old logs open, and
will still be writing to it -- meaning disk space will still be taken
up, even though you won't see the file growing.
The commercial webserver Zeus solves this problem elegantly: youD
It has an option called tuning!logmanager_open_as_root, which defaults
to no. You can turn this on and have logfiles opened as root.
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
