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.
@ Maintainers(s): Please tell us how you want to proceed here. Should security take action or will you look into this?
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.
Hello- If I'm not mistaken, passing "--no-dereference" to chown should mitigate this finding. Thank you
(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.)
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
commit 2310b0cd4914c79b2e8f3cb424259bb6e635a195 Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-09-18 21:16:58 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-09-18 21:16:58 +0000 net-analyzer/smokeping: treeclean Bug: https://bugs.gentoo.org/631140 Signed-off-by: John Helmert III <ajak@gentoo.org> net-analyzer/smokeping/Manifest | 1 - net-analyzer/smokeping/files/79_smokeping.conf | 15 --- net-analyzer/smokeping/files/smokeping.conf | 1 - net-analyzer/smokeping/files/smokeping.init.5 | 56 --------- net-analyzer/smokeping/files/smokeping.service | 10 -- net-analyzer/smokeping/metadata.xml | 12 -- net-analyzer/smokeping/smokeping-2.7.3-r1.ebuild | 143 ----------------------- profiles/package.mask | 5 - 8 files changed, 243 deletions(-)
GLSA request filed, CVE pending
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=2570332a2b988e5bec8319e9b7bcfceb39048f5d commit 2570332a2b988e5bec8319e9b7bcfceb39048f5d Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-09-25 13:55:57 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-09-25 13:55:57 +0000 [ GLSA 202209-08 ] fix bug reference typo Bug: https://bugs.gentoo.org/602652 Signed-off-by: John Helmert III <ajak@gentoo.org> glsa-202209-08.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
GLSA released, all done!
