/var/log/lighttpd is unsafe

[MadCoder]

lighttpd by default uses /var/log/lighttpd/*.log file that are readable _and_ writeable by the user lighttpd is running under. That wouldn't be a big problem if only static files would be served. But with CGI scripts, this becomes a _huge_ security problem, as an attacker could use that to erase his tracks.

FWIW this is Debian #406338

[darix]

this is more a packaging bug and not and issue of lighttpd itself.

[MadCoder]

If I set the logs owned by root:adm (as they should be), here is what lighttpd spits before dying:

Starting web server: lighttpd2007-07-29 01:02:39: (mod_accesslog.c.514) opening access-log failed: Permission denied /var/log/lighttpd/access.log 2007-07-29 01:02:39: (server.c.849) Configuration of plugins failed. Going down.

So either this has been fixed since 1.4.13 and that's odd because it's not mentionned in the changelogs, or lighttpd does not supports safe access logs by default.

-- The Packager.

[darix]

ok. 1. why should the logs be owned by root:adm? 2. how do you expect the logs to be opened by someone who is not root?!

or does adm allow writing? i doubt that.

3. lighttpd needs to be able to reopen the files for writing after logrotate e.g. so even if we would open the logs while lighttpd is still root. it would fail on logrotate.

that said ... lighttpd needs to be able to write those files and reopen them. so imho those files should be owned by the user that lighttpd runs as. for my packages i run lighttpd as user lighttpd and the /var/log/lighttpd is owned by the same user as lighttpd. and only the lighttpd user can write to it.

unlike apache there is no part of lighttpd still running as root after startup.

an option might be to use a pipe logger (cronolog comes to mind) and use that. sadly it would require an suid binary. last but not least you could use syslog support.

that said... fixing this the apache way would require some major changes to lighttpd and i dont see that happen.

[darix]

last but not least ... protecting the system from those CGI apps could be easily achieved with AppArmor? or grsecurity.

[MadCoder]

I fail to see how grsecurity can disallow cgis to write into /var/log/lighttpd whereas lighttpd can. And to fix that, there is an easy solution. logrotate supports the "copy" option that copies the content of the log file, letting it unchanged (especially its inode).

lighttpd could open the log file while it is running as root, letting it be owned by root, dropping privilegies, and caring a lot about not closing that file. It seems pretty easy to me. I don't know the gory details of logrotate with the copy option, as it's not an atomic operation, care has to be taken to ensure no log is lost. But this is definitely doable.

Of course people that run lighttpd without being root won't benefit from this, but their server can't run on the :80 port either anyway, so I think it wouldn't be that of a problem.

Thinking that if CGI write in /var/log/lighttpd it's the CGIs fault is correct, though the httpd should prevent that, because else it's praying for the CGIs to be safe, which well, isn't realistic.

[Olaf van der Spek]

If both the web server and CGIs run as www-data, isn't the web server vulnerable to those CGIs anyway (strace, kill etc seem to be able to affect the web server)?

I think the ideal solution would be to use a pipe logger (why does that require suid?) such that the web server (and basically all other apps that use logrotate) is shielded from logrotates.

[MadCoder]

Replying to Olaf van der Spek:

If both the web server and CGIs run as www-data, isn't the web server vulnerable to those CGIs anyway (strace, kill etc seem to be able to affect the web server)?

Of course, but if the loggers are not touchable, and that you always log first, when an attacker uses a CGI flaw, even if it kills the http server, it's logged, hence the admin can know what happened, or at least when it happened.

[Olaf van der Spek]

Of course, but if the loggers are not touchable,

But that requires not using logging directly to file.

[darix]

Replying to Olaf van der Spek:

If both the web server and CGIs run as www-data, isn't the web server vulnerable to those CGIs anyway (strace, kill etc seem to be able to affect the web server)?

that would be the bigger issue imho.

I think the ideal solution would be to use a pipe logger (why does that require suid?) such that the web server (and basically all other apps that use logrotate) is shielded from logrotates.

because it is launched as www-data user.

[darix]

Replying to MadCoder:

I fail to see how grsecurity can disallow cgis to write into /var/log/lighttpd whereas lighttpd can.

all my CGI/FastCGI applications have an apparmor profile and that only allows them to open files specified in the profile. the log file is not part of it of course.

[Olaf van der Spek]

because it is launched as www-data user.

Why don't you start it either before the web server is started or before the web server switches to www-data?

[jan]

Replying to Olaf van der Spek:

because it is launched as www-data user.

Why don't you start it either before the web server is started or before the web server switches to www-data?

As we can't cycle the logfiles when we don't have write permissions as normal user.

[Olaf van der Spek]

As we can't cycle the logfiles when we don't have write permissions as normal user.

But the pipelogger would run as root and so does have that permission.

[Olaf van der Spek]

Actually it doesn't have to run as root, it just has to run as a user not equal to the user of the web server itself.

[stbuehler]

Oh big news... CGI without suid wrapper or apparmor/... isn't secure!

...

You don't need lighttpd to start the pipelogger, you could have a logger listening on a socket/pipe and have cat/netcat forward it from lighttpd.