Headline
CVE-2017-20148: root privilege escalation via "chown -R" in pkg_postinst
In the ebuild package through logcheck-1.3.23.ebuild for Logcheck on Gentoo, it is possible to achieve root privilege escalation from the logcheck user because of insecure recursive chown calls.
Description Michael Orlitzky 2017-09-11 22:45:48 UTC
The logcheck ebuilds all call “chown -R” on the root filesystem during pkg_postinst:
pkg_postinst() { chown -R logcheck:logcheck /etc/logcheck /var/lib/logcheck || die
This is exploitable in the same way that the init scripts were: the first install is safe, but then the logcheck user can place a hard link in either of those directories pointing to e.g. /root/.bashrc. The next time logcheck is installed, the ebuild will call chown on the hardlink, and give ownership of /root/.bashrc to the “logcheck” user.
I’m marking this private, but the package is maintainer-needed, so it’s up to @security who to CC. If someone wants to take a shot at it, my first attempt would be to use “fowners root:logcheck …” and to do it on $D in src_install. Another call to fperms could then make those directories group-rwx. Neither call should operate recursively.
Comment 1 Kristian Fiskerstrand (RETIRED) 2017-09-12 08:58:55 UTC
@mrueg: Hi Manuel, I see you’re the last dev to touch this package with a version bump earlier this year. Maybe you want to take a crack at fixing this issue and taking over maintainership of the package?
Comment 2 Manuel Rüger (RETIRED) 2017-09-12 12:41:59 UTC
I’m not interested in maintaining it.
the cronjob is probably similarly vulnerable in /etc/cron.hourly/logcheck.cron > chown -R logcheck:logcheck /var/lock/logcheck
Comment 6 Manuel Mommertz 2022-08-26 06:03:12 UTC
Created attachment 801076 [details, diff] Fix privilege escalation
If it is just the privilege escalation, this is easily fixable (see patch).
Regarding a maintainer I cannot help, sorry. :)
Comment 7 Philippe Chaintreuil 2022-08-26 11:18:18 UTC
I’d be willing to proxy maintainer logcheck to keep it in the tree.
Comment 9 Jared B. 2022-08-29 19:20:30 UTC
Also, there was a comment about logcheck being “unmaintained since the git transition” in the last rights, but I can’t figure out what that’s referring to. It seems like this is the current git repo:
https://salsa.debian.org/debian/logcheck
And that had a commit 2 weeks ago, plus several commits and a new release (1.3.24) in July. So this doesn’t seem to be unmaintained, though admittedly this is an outsider’s view and there may be stuff behind the scenes that I don’t see.
Comment 11 Jared B. 2022-08-31 13:08:50 UTC
(In reply to John Helmert III from comment #10) > The last maintainer in Gentoo dropped the package in 2017:
Gotcha. I had read that as unmaintained upstream. Thanks for clarifying.
Comment 12 Philippe Chaintreuil 2022-09-16 00:13:35 UTC
(In reply to Sam James from comment #8) > (In reply to Philippe Chaintreuil from comment #7)
I’d be willing to proxy maintainer logcheck to keep it in the tree.
That’d be great, thank you.
Actually, I’m going to have to retract this. Turns out I’m still using logsentry, not logcheck. (I was confused since logsentry’s script is called logcheck.) Sorry for the fake-out. :-(
Related news
Gentoo Linux Security Advisory 202209-10 - A vulnerability has been discovered in Logcheck's ebuilds which could allow for root privilege escalation. Versions less than or equal to 1.3.23 are affected.