Re: Bug#554893: startup script should be more careful with chown -R
reopen 554893
thanks
[Cc'ing debian-devel because it's wrong to call valid claims "bogus"
and closing security bugs without any changes, especially since the
issue at hand in the package actually is bogus from the beginning]
Pierre Habouzit wrote:
On Sat, Nov 07, 2009 at 08:48:35AM +0300, Michael Tokarev wrote:
Package: nsd3
Version: 3.2.3-1
Severity: normal
Tags: patch
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
is mine.
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.
---
To be able to do ln /etc/shadow /var/run/nsd3/shadow (because passwd
isn't very interesting and already world-readable), not only you need it
to be the same file system, but you need to be root in the first place.
You don't understand.
The nsd startup script does chOWN. So if it is /etc/shadow or /etc/passwd
and we chOWNed it to nsd user, the system is now owned by nsd. It does
not matter if /etc/passwd was readable or not, it becomes OWNED by the
wrong user.
But as I said, it's not the case here, since /etc is on different filesystem
most likely (not guaranteed but in that case it's local operator error).
/var/run/utmp, also mentioned by me above, *is* on this very filesystem
(be it on tmpfs or not).
/var/run/* is void at boot time, so the mkdir + chown is a common
practice in init scripts, and cannot be attacked the way you describe.
I recall the beginning of my bugreport, again:
---
Current /etc/init.d/nsd3 contains the following code which gets executed
_every_ time the script is run, even before checking the cli arguments:
^^^^^^^
---
Note the word "every" here. Again, slowly: _every_ invocation of that
script does that.
Now, the script is not just startup script. It is THE way for nsd package
to rebuild the zone files -- by using `/etc/init.d/nsd reload'. Upstream
provides nsdc script for this, but it does not do setuid/su, and files gets
created as owned by root. So the preferred way to regenerate the zone files
after any change is to run the startup script.
Now, and this is again mentioned in my initial report, the issue at hand is
not an issue to start with. Wha't is written in the startup script is bogus.
There's no need to chown a _newly_ _created_ directory RECURSIVELY to start
with.
I hope that you finally see what I'm talking about. Please don't close the
bug before understanding the issue.
Thank you.
/mjt
Reply to: