oss-sec mailing list archives

Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation


From: Daniel Kahn Gillmor <dkg () fifthhorseman net>
Date: Thu, 07 Sep 2017 12:22:11 -0400

On Thu 2017-09-07 08:38:23 -0400, Michael Orlitzky wrote:
I've been reluctant to do this because I'm approaching these as an
OpenRC user, and OpenRC has the ability to supervise the daemon. I
always hate it when someone makes a suggestion (at my expense) that
amounts to "I don't need this, so you don't need this" -- and I don't
want to be /that/ guy.

You don't need to be /that/ guy to point out that there are multiple
possible approaches to managing services, and some service management
approaches are simply less vulnerable to this stuff than others.

You're helping to identify a class of problems here that need to be
eliminated.  I don't think we do anyone any favors by hiding the fact
that the class of problems can be completely avoided by using systemd,
openrc, runit, s6, /sbin/init, etc.

I've found services that run with *two* PID files, one of which is
ignored. I've found services that go out of their way to give away
ownership of /run/foo, even though /run/foo/foo.pid is created and owned
by root. Pretty much any way you can go wrong has made an appearance at
least once, and all of these are for daemons that should be supervised
-- the service scripts should be trivial.

sigh.  are you cataloging these somewhere?  this is really valuable
work, and it'd be great to see a list of common failures.  Do you know
if any of them are collected under CWE or any other widely-accepted
taxonomy?

Is there any way to automate these tests, or do we need a human to read
each initscript and look for flaws?  Are other people helping you in
this review?  how are you tracking/coordinating your reviews?

Anyway, my point is, it may be optimistic to think that we can help
people not do weird things in their service scripts =)

thank you for doing this review, but i disagree with your conclusion --
you're already helping people to not do weird things in their service
scripts, just by writing these reports :)

You might not be able to prevent all the bad from happening, but
establishing what a bad practice looks like will help people push back
against those practices in the future.

Regards,

         --dkg

Attachment: signature.asc
Description:


Current thread: