Re: Bug#554893: startup script should be more careful with chown -R
Michael Tokarev wrote:
Pierre Habouzit wrote:
On Sat, Nov 07, 2009 at 08:48:35AM +0300, Michael Tokarev wrote:
Current /etc/init.d/nsd3 contains the following code which gets executed
_every_ time the script is run, even before checking the cli arguments:
--- cut ---
mkdir -p /var/run/nsd3 && chown -R "$nsd_user" /var/run/nsd3
--- cut ---
This is dangerous from the security point of view.
I already reported similar issue in nsd package, with uncertain effect.
So let me describe the background again.
Network daemons usually are run under special unprivileged user account.
This is done in order to minimize possible harm that can be done if the
daemon gets compromised: basically, when daemon is running with only
limited set of privileges it may not do as much bad as if it were
running as root. This is a commonly recognized principle.
In a similar way, special care should be taken when dealing with
directories writable by network daemons, treating them as untrusted data
the same way as we don't trust daemon itself. Because if the daemon is
compromised, an attacker is able to manipulate these files, including
creating various tricks to gain more privileges.
Here, we are unconditionally and recursively chown'ing whole directory
owned by the network-facing daemon, while running as root. That
directory may contain, for example, links (created by an attacker who
successfully exploited a bug in nsd) to other files which will be owned
by nsd user after we executed chown.
Just to show an example - it's obviously not as simple as that because
/var/run and / are usually on different filesystems: I, as a "bad
guy", can do
ln /etc/passwd /var/run/nsd/passwd
and wait till admin executes /etc/init.d/nsd3. After which the system
this is bogus, /, /var, /var/run are 755 root:root. Your so called
attack isn't one.
Yes _this_ example is bogus, and the very next paragraph in the original
bug report (which you removed) tells you just that. Here it is again:
In real life it's not as bad obviously, I will be able to manipulate
only pid files mostly (in /var/run which is a tmpfs), but I will also
be able to manipulate /var/run/utmp this way too, which is a base for
getlogin() for example. Also not a bad thing for the next attack vector.
I stand corrected.
And as others in #debian pointed out the overlooked obvious, `chown -R'
follows symlinks. So it's sufficient to put a symlink to /etc/passwd into
/var/lib/nsd3 to get the system 0wned.
So, bug in nsd that lets you to write to the filesystem and the whole system