Description Michael Orlitzky 2018-07-29 20:42:23 UTC

Our sys-apps/man-db package installs the /usr/bin/mandb program setuid and setgid with owner/group "man". We also install a daily cron job from ${FILESDIR}/man-db.cron that runs as root and executes,

exec nice mandb --quiet

This can be exploited by the “man” user to gain root privileges. For example, the “man” user can simply strip off the setuid/setgid bits:

su man -s /bin/sh -c ‘chmod 755 /usr/bin/mandb’

Now when “mandb” is run in the cron job, it will run with root privileges. But the owner of /usr/bin/mandb has not changed, so the “man” user can write to it because he owns it:

su man -s /bin/sh -c ‘cat < bad-script.sh > /usr/bin/mandb’

Whenever the cron job runs again, the “man” user gains root.

Comment 1 Thomas Deutschmann (RETIRED) 2018-07-29 22:25:48 UTC

Mh, this sounds like bug 602588…

Comment 2 Michael Orlitzky 2018-07-29 23:06:50 UTC

(In reply to Thomas Deutschmann from comment #1) > Mh, this sounds like bug 602588…

I saw that, but the gist of this one is more “the executable shouldn’t be owned by ‘man’ to begin with.” The fact that the cron job makes it easy to exploit is only adding insult to injury. If root (or another privileged user) was ever going to run /usr/bin/mandb for any reason, then the “man” user could swap out its contents beforehand.

Comment 4 Colin Watson 2018-09-17 13:00:04 UTC

I don’t think those commits are especially related, except perhaps insofar as they describe existing practice.

This sort of thing is indeed a problem with having setuid-to-non-root executables that might be run as root: such a setup inherently means that root has to trust the user that owns the executable. I can see a few non-exclusive options:

1. Make mandb setuid root instead, and add code at the start of main() (or maybe in init_security() or something) to drop to MAN_OWNER if necessary.
2. Mitigate the bug by making the cron job run as the man user rather than root; at least then it isn’t *guaranteed* that mandb will be run as root. (Note that Debian’s cron jobs have run as the man user for at least 17 years.)
3. Stop installing mandb setuid by default.

Option 1 might be a good idea, and is probably the only way to preserve the setuid setup while immunising against this bug. On the other hand, it adds a bit more attack surface and would have to be done carefully.

Option 2 seems to have no obvious downsides. Assuming it works in the Gentoo setup, you surely ought to do this even if it isn’t a complete fix for this bug.

Option 3 is almost certainly the right long-term fix.

Comment 6 Lars Wendler (Polynomial-C) (RETIRED) 2019-01-06 15:13:23 UTC

Michael, please check if this attempt is sufficient to get rid of this root escalation issue.

Comment 7 Michael Orlitzky 2019-01-06 16:09:49 UTC

(In reply to Lars Wendler (Polynomial-C) from comment #6) > Michael, please check if this attempt is sufficient to get rid of this root

escalation issue.

In the past, I’m almost certain that portage would not change the owner or group of a file that already exists during merge. So, I was expecting /usr/bin/mandb to still be “man:man” after an upgrade.

Good news: it isn’t!

Bad news: I don’t know why, or if we can rely on that happening. I’m going to ask around to see if something changed in portage to make this reliable.

But the fix generally looks good to me. In the future you might want to create /var/cache/man in src_install, so that you don’t have to do it in both the cron job and pkg_preinst, and you don’t have to chown/chmod it every time (this can also be dangerous if /var/cache isn’t owned by root).

Then, instead of the shell script cron job that we have now, you could put something simpler in /etc/cron.d:

<minute> <hour> * * * man mandb --quiet

Comment 8 Michael Orlitzky 2019-01-07 16:04:57 UTC

(In reply to Michael Orlitzky from comment #7) >

In the past, I’m almost certain that portage would not change the owner or group of a file that already exists during merge. So, I was expecting /usr/bin/mandb to still be “man:man” after an upgrade.

This still happens for directories but not for files. I tested back to portage-2.3.6, so we’d best assume the simplest explanation: I’m remembering wrong, and the ownership of *files* will be updated.

Comment 9 Lars Wendler (Polynomial-C) (RETIRED) 2019-01-11 09:02:34 UTC

(In reply to Michael Orlitzky from comment #7) >

But the fix generally looks good to me. In the future you might want to create /var/cache/man in src_install, so that you don’t have to do it in both the cron job and pkg_preinst, and you don’t have to chown/chmod it every time (this can also be dangerous if /var/cache isn’t owned by root).

No can do as this would put the content of /var/cache/man into the package’s content which we wanna avoid (by doing it in pkg_preinst).

> Then, instead of the shell script cron job that we have now, you could put

something simpler in /etc/cron.d:

<minute> <hour> * * * man mandb --quiet

That sounds like a good idea. Care to file a separate bug for that?