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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Michael Tokarev wrote:
[]

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.
---


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
is 0wned.

/mjt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Nov 08, 2009 at 06:11:20PM +0300, Michael Tokarev wrote:
> 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]

For all I care you cannot exploit this bug, unless you can make the nsd
user write symlink to files there. If this is asking for trouble, and my
next upload is going to fix that, it's not really worth the fuss about
cc-ing d-d@...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org

On Sun, Nov 08, 2009 at 07:13:25PM +0300, Michael Tokarev wrote:
[...]
> 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.
[...]

Not to downplay the original bug (removed from Cc), but have you
tested the above claim? This didn't match my recollection, so I
checked and found (at least using the one from coreutils under sid)
that chown doesn't follow either symlinks in the tree or even
specified as a parameter...

$ whoami
user1
$ mkdir foo bar
$ touch bar/baz
$ ln -s ../bar foo/xyzzy
$ ln -s ../bar/baz foo/plugh
$ sudo chown -R user2:user2 foo
$ ls -al bar
total 3
drwxr-xr-x 2 user1 user1 72 2009-11-08 17:15 .
drwx--x--x 38 user1 user1 2648 2009-11-08 17:14 ..
-rw-r--r-- 1 user1 user1 0 2009-11-08 17:15 baz
$ ls -al foo
total 3
drwxr-xr-x 2 user2 user2 96 2009-11-08 17:15 .
drwx--x--x 38 user1 user1 2648 2009-11-08 17:14 ..
lrwxrwxrwx 1 user2 user2 10 2009-11-08 17:15 plugh -> ../bar/baz
lrwxrwxrwx 1 user2 user2 6 2009-11-08 17:15 xyzzy -> ../bar
$ sudo chown -R user2:user2 foo/xyzzy
$ ls -al foo/xyzzy/
total 3
drwxr-xr-x 2 user1 user1 72 2009-11-08 17:15 .
drwx--x--x 38 user1 user1 2648 2009-11-08 17:14 ..
-rw-r--r-- 1 user1 user1 0 2009-11-08 17:15 baz
$ sudo chown -R user2:user2 foo/plugh
$ ls -al bar
total 3
drwxr-xr-x 2 user1 user1 72 2009-11-08 17:15 .
drwx--x--x 38 user1 user1 2648 2009-11-08 17:14 ..
-rw-r--r-- 1 user1 user1 0 2009-11-08 17:15 baz

Unless I'm missing something subtle, symbolic links shouldn't be a
concern here.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@yuggoth.org); IRC(fungi@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@yuggoth.org);
MUD(fungi@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org