On 02/09/12 08:44, Michael Tokarev wrote:
Package: dnsmasq
Version: 2.55-2
Severity: serious
Tags: security

The initscript (and postinst script) of dnsmasq creates /var/run/dnsmasq
directory and chowns it to dnsmasq:nogroup.  However, dnsmasq daemon writes
the pidfile (which apparently is the only file there) as root user.  Here's
the code which does this (in src/dnsmasq.c):

           FILE *pidfile;

           /* only complain if started as root */
           if ((pidfile = fopen(daemon->runfile, "w")))
             {
               fprintf(pidfile, "%d\n", (int) getpid());
               fclose(pidfile);
             }

So there's no checking for this file to exist, being a symlink etc.

This way, we effectively making dnsmasq user equal to root: dnsmasq
user can (sym)link /var/run/dnsmasq/dnsmasq.pid to, say, /etc/shadow,
and it will be overwitten the next time dnsmasq (re)starts.  This is
obviously wrong.

The only good side of this is that dnsmasq writes only controlled data
to this file (its pid, as per above), so the damage is minimal, ie,
only a denial of service, not gain of service (hence Severity is only
"serious").

Besides, documentation says the pid file is /var/run/dnsmasq.pid, not
/var/run/dnsmasq/dnsmasq.pid - it is the initscript which sets the option
"behind the scenes".  Also, there's no mentions in the changelog about
WHY pid file is in this location.  And more, it one can change the user
dnsmasq runs as.

It looks like this pidfile stuff needs to be removed entirely (moving
it to a subdir silently and chowning that subdir to dnsmasq user).

Thanks,

/mjt


The explanation for the current state of affairs is here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508560

/var/run/dnsmasq is owned by user dnsmasq so that dnsmasq can unlink the pid file when it shuts down, even though at that point it is running as user "dnsmasq", not as user "root".

I can see a couple of ways of fixing this, without just removing the whole edifice, but neither are perfect.

1) stat the pid file and check for symlinks, etc (or just unlink it) just before creating the new one. There's a race between the unlink and the creation though - an attacker could create the symlink then.

2) Create the pid file after changing user. That works fine in this case, but not in the default case when dnsmasq writes to /var/run/dnsmasq.pid and then changes to user "nobody". The behaviour would therefore need to be enabled by a special config option or risk breaking nearly every dnsmasq installation other than Debian/Ubunutu.


Simon.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to