Project

General

Profile

Actions

Bug #2365

closed

Privileges not dropped when setting up configuration. Can overwrite ANYTHING in the system

Added by slv over 12 years ago. Updated over 12 years ago.

Status:
Invalid
Priority:
Normal
Category:
-
Target version:
-
ASK QUESTIONS IN Forums:

Description

Hi,

I'm a PhD student developing ConfErr v2, a tool that tests the reaction of systems to configurations caused by realistic human errors.

Lighttpd is one of the systems I use to run experiments on. I use Lighttpd 1.4.28 with build date Aug 20 2011 20:31:21 on Ubuntu 11.10.

To my surprise, while looking over how the experiments progressed, I saw that perl wasn't working anymore. It read something like "cannot execute command 12345 at line: 1".
After investigating a bit, I found the culprit: my tool caused the server.pid-file directive to point to /usr/bin/perl, so when writing the PID of the lighttpd process, it overwrote perl.

What made it more puzzling was the fact that lighttpd was running as www-data (which was set through the server.username option,) with no right to overwrite /usr/bin/perl.
I started lighttpd as root, as per the lighttpd documentation (http://redmine.lighttpd.net/wiki/1/Server.usernameDetails) that says root-permissions is required to start lighttpd.

My guess at the explanation for the overwrite is that lighttpd doesn't drop its root privileges until after it sets up the configuration. But, by this point, considerable damage can be done to the system. Moreover, if you do not run any perl scripts, you won't notice the problem right away.

The fact that perl has been overwritten means, at least for Ubuntu, that one cannot install or reinstall any packages because ubuntu uses perl to set them up (this is what I've noticed from my experience.)

Intrigued, I pointed the server.pid-file directive to a linux kernel image. It overwrote that one too.

This is clearly a bug, because Lighttpd should drop the privilege before overwriting the PID file.

Best regards,
Silviu

Actions #1

Updated by slv over 12 years ago

  • Target version set to 1.4.x
Actions #2

Updated by icy over 12 years ago

You can also cripple your box by just putting include_shell "rm -rf /" in it. There are probably tons of ways to cause harm to your system.
And dropping the priviledge after the config file is executed would prevent certain features.

I do not see a way to write a fool proof config system. If people do stupid stuff like setting the pid-file path to the perl binary... tough luck.

Actions #3

Updated by stbuehler over 12 years ago

  • Status changed from New to Invalid

It should not drop privs before writing the pid-file, otherwise it could be modified by cgi scripts later.

Actions #4

Updated by slv over 12 years ago

  • Status changed from Invalid to Reopened

The principle of "least privilege" seems important for a server that needs to be secure. To observe this principle and get rid of the problem reported above, it is sufficient in src/server.c to wrap

if (-1 == (pid_fd = open(srv->srvconf.pid_file->ptr, O_WRONLY | O_CREAT | O_EXCL | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH))) {
        ...
}

in a drop-privilege followed by a restore-privilege:

struct passwd * pwd = NULL;
if (NULL == (pwd = getpwnam(srv->srvconf.username->ptr))) {
        return -1;
}
uid_t lo_uid = pwd->pw_uid;
uid_t hi_uid = getuid();
seteuid(lo_uid);
if (-1 == (pid_fd = open(srv->srvconf.pid_file->ptr, O_WRONLY | O_CREAT | O_EXCL | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH))) {
        ...
}
seteuid(hi_uid);
chown(srv->srvconf.pid_file->ptr, getuid(), getgid());

This does not affect the rest of the server's operation.

Actions #5

Updated by stbuehler over 12 years ago

  • Status changed from Reopened to Invalid

You didn't read what i wrote, bye.

Actions #6

Updated by slv over 12 years ago

Hi,

How exactly can the PID file owned by root be modified by CGI scripts later?

In my suggested fix, the PID file is opened with the privileges of the srv->srvconf.username user, but then its owner is changed to root, using the chown statement.
There is only a small window of time, between when the PID file is opened and the respective chown statement, when the file is not owned by root, but in that window, the server is not yet serving requests, so no CGI scripts are running.

Actions #7

Updated by stbuehler over 12 years ago

And the migration path for all systems on which the pid file is owned by root right now? And where is the sane error handling (like handling a not set username...)?

The configfile is written by root, and if you do stupid things like that it is your own damn fault. I'm not gonna put more time into this, there are way more important things to do.

Actions #8

Updated by stbuehler over 12 years ago

  • Target version deleted (1.4.x)
Actions

Also available in: Atom