Headline
CVE-2016-20015: root privilege escalation via race condition in init script
In the smokeping-2.7.3-r1.ebuild package for SmokePing on Gentoo, the initscript allows the smokeping user to gain ownership of any file, allowing for the smokeping user to gain root privileges. There is a race condition involving /var/lib/smokeping and chown.
Description Michael Orlitzky 2016-12-14 15:47:14 UTC
The smokeping ebuilds give ownership of /var/lib/smokeping to the “smokeping” user:
fowners smokeping:smokeping /var/lib/${PN}
The init script has a “restore” command that trusts the contents of that directory too much:
for f in `find /var/lib/smokeping -name ‘*.xml’ -print` ; do f_rrd=`dirname $f`/`basename $f .xml`.rrd mv -f “${f_rrd}” “${f_rrd}.bak” chown root:0 “${f_rrd}.bak” rrdtool restore “$f” “${f_rrd}” chown smokeping:smokeping “${f_rrd}” done
The last “chown” can be used to gain root privileges, because $f_rrd can be changed to a symlink between the “mv” and “chown” calls.
I was actually able to exploit this. First, create some files (as the smokeping user) so that the “find” command above has something to play with:
$ ln -sf /home/mjo/foo.txt /var/lib/smokeping/test.rrd $ touch /var/lib/smokeping/test.xml
Now the “restore” action will rename test.rrd, attempt to restore a dump, and then call chown on test.rrd, which it expects contains the restored data. But you can trick it: as the smokeping user, execute,
while true; do ln -sf /home/mjo/foo.txt /var/lib/smokeping/test.rrd; done;
If you’re lucky, one of those links will get created between the “mv” and the "chown", and the init script will change ownership of the symlink target to smokeping:smokeping. (On my machine, it changes /home/mjo/foo.txt to smokeping:smokeping.)
Thus the smokeping user can take ownership of any file on the system.
Comment 1 Thomas Deutschmann 2017-01-08 23:26:13 UTC
@ Maintainers(s): Please tell us how you want to proceed here. Should security take action or will you look into this?
Comment 2 Thomas Deutschmann 2019-12-26 15:28:35 UTC
This is now public.
Please take action (if you cannot fix but still care about package, drop restore function from runscript at least) or let treecleaners last rite.
Comment 3 nic 2021-09-19 20:20:34 UTC
Hello- If I’m not mistaken, passing “–no-dereference” to chown should mitigate this finding.
Thank you
Comment 4 Michael Orlitzky 2021-09-28 14:13:32 UTC
(In reply to nic from comment #3) > Hello-
If I’m not mistaken, passing “–no-dereference” to chown should mitigate this finding.
The same trick works with hard links, and --no-dereference doesn’t help with that. I think the “restore” process really just needs to run as smokeping:smokeping and not as root. (I am assuming that the “chown root:0” line does nothing important.)
Comment 5 nic 2022-03-04 03:14:13 UTC
Appreciate your insights. From a user perspective, I’d support removal this function if a solution is not forthcoming. I suspect not many folks have a need to run this often, as I’ve only needed to do so when migrating rrd between arches.
Maybe consider adding doco as einfo statements or into the wiki? “sudo -u smokeping rrdtool restore foo.xml foo.rrd”
Thank you