oss-sec mailing list archives
Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation
From: Michael Orlitzky <michael () orlitzky com>
Date: Mon, 11 Sep 2017 15:58:45 -0400
On 09/07/2017 12:22 PM, Daniel Kahn Gillmor wrote:
I've found services that run with *two* PID files...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?
I collected a bunch of common problems into a pull request for OpenRC: https://github.com/OpenRC/openrc/pull/162 I would like to have something more comprehensive for init script writers, but we would need to consolidate some of the existing documentation from both OpenRC and various Gentoo sources. With OpenRC we get to cheat a little, because we always have the option to run the daemon in the foreground and supervise it. A comparable document for SysV init script writers would need different workarounds for the problems that OpenRC services solve in that manner. The motivation for those tips can be found in the Gentoo bugs I've been filing on bugs.gentoo.org. You can find most of them by searching for "pid" in the summary with "mjo () gentoo org" as the reporter (don't forget to include resolved bugs). It's slow going because I'm trying to provide either a complete list of suggestions, or a rewritten init script that does things right.
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?
It's just me as far as I know. I stumbled onto this by accident while cleaning up an OpenRC init script that was shipped as part of an upstream package. I updated it, and then noticed that my init script was vulnerable to the PID file trick. Then I realized that everybody else has the same problem. You probably need a human to make the final decision on whether or not an init script is vulnerable, but my lame heuristic so far has been hilariously accurate: does the init script mess with file/directory ownership? If so, it's probably vulnerable to *something*. I've still got a list of 100 or so to investigate that change ownership of a directory under /var/run. Very few of those will be false positives -- it's OK to put a socket or lock file there, but not a PID file.
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Michael Orlitzky (Aug 16)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Daniel Kahn Gillmor (Aug 16)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Michael Orlitzky (Aug 18)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Daniel Kahn Gillmor (Sep 06)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Michael Orlitzky (Sep 07)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Simon McVittie (Sep 07)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Daniel Kahn Gillmor (Sep 07)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Simon McVittie (Sep 07)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Daniel Kahn Gillmor (Sep 07)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Michael Orlitzky (Aug 18)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Daniel Kahn Gillmor (Aug 16)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Daniel Kahn Gillmor (Sep 07)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Michael Orlitzky (Sep 11)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation Simon McVittie (Sep 11)
- Re: CVE-2017-12847: nagios-core privilege escalation via PID file manipulation kseifried () redhat com (Sep 11)