Security
Headlines
HeadlinesLatestCVEs

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.

CVE
#mac

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

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda