[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb6b7e2d-977d-7eae-346e-a638f806bf34@orlitzky.com>
Date: Thu, 7 Sep 2017 08:38:23 -0400
From: Michael Orlitzky <michael@...itzky.com>
To: oss-security@...ts.openwall.com
Cc: Daniel Kahn Gillmor <dkg@...thhorseman.net>
Subject: Re: CVE-2017-12847: nagios-core privilege escalation
via PID file manipulation
On 09/06/2017 05:15 PM, Daniel Kahn Gillmor wrote:
>
> But i think future reports of problems with pidfiles (e.g. your helpful
> cleanup of mimedefang -- thanks!) should always include the suggestion
> to disable pidfiles entirely and to encourage developers who must
> implement them to ensure that they're only an extra feature, for use
> with otherwise limited service managers, and perhaps to be compile-time
> disabled.
>
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.
I think a compile-time option is reasonable, though. Maybe the ability
to fork into the background should also be compiled out in that case.
When I encounter more of these, I'll provide a list of possible
solutions and include "get rid of the PID file" along with its trade-offs.
Most of the PID file vulnerabilities that I've found are in the
distribution init scripts: the only ones that hit this list are the
upstream projects that make it impossible for the distro developers to
get it right. Curiously though, a lot of the problems that I've found in
the distro scripts are for daemons that run in the foreground and are
supposed to be supervised.
Basically, there are two accepted approaches. Forking,
1. Daemon forks
2. Daemon writes a PID file
3. Daemon drops privileges
And supervised:
4. Daemon runs in the foreground, and does nothing special
What I've found is that many programs choose any old subset of (1)
through (4), and implement them in any order. As a result, init script
authors haven't developed a feel for the right way to do things; they
copy/paste snippets from other init scripts until things seem to work.
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.
Anyway, my point is, it may be optimistic to think that we can help
people not do weird things in their service scripts =)
Download attachment "signature.asc" of type "application/pgp-signature" (982 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
