Bug 628086 (CVE-2017-12847) – <net-analyzer/nagios-core-4.3.3: daemon should create its PID file before dropping privileges (CVE-2017-12847)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Aleksandr Wagner (Kivak) 2017-08-17 08:44:57 UTC]

From $URL:

Product: Nagios Core
Versions-affected: 4.3.2 and earlier
Fixed-in: commits 1b19734 and 3baffa7, version 4.3.3
Bug-report: https://github.com/NagiosEnterprises/nagioscore/issues/404
Author: Michael Orlitzky
Acknowledgments: Bryan Heden (upstream) for his fast response and help

== Summary ==

The nagios daemon should create its PID file before dropping
privileges. This represents a minor security issue; additional factors
are needed to make it exploitable.

== Details ==

The purpose of the PID file is to hold the PID of the running daemon,
so that later it can be stopped, restarted, or otherwise signalled
(many daemons reload their configurations in response to a SIGHUP).
To fulfill that purpose, the contents of the PID file need to be
trustworthy. If the PID file is writable by a non-root user, then he
can replace its contents with the PID of a root process. Afterwards,
any attempt to signal the PID contained in the PID file will instead
signal a root process chosen by the non-root user (a vulnerability).

This is commonly exploitable by init scripts that are run as root and
which blindly trust the contents of their PID files. Nagios itself ships
such an init script (daemon-init.in), so the risk is not theoretical in
this case.

== Exploitation ==

An example scenario involving an init script would be,

1. I run "/etc/init.d/nagios start" to start the daemon.

2. nagios drops to the "nagios" user.

3. nagios writes its PID file, now owned by the "nagios" user.

4. Someone compromises the daemon, which sits on the network.

5. The attacker is generally limited in what he can do because the
   daemon doesn't run as root. However, he can write "1" into the
   PID file, and he does.

6. I run "/etc/init.d/nagios stop" to stop the daemon while I
   investigate the weird behavior resulting from the hack.

7. The machine reboots, because I killed PID 1 (this is normally
   restricted to root).

== Resolution ==

The problem is avoided by creating the PID file as root, before dropping
privileges.

[Comment 1 Michael Orlitzky 2017-08-17 12:20:33 UTC]

Fixed yesterday before I sent the email =)

Stabilize when ready, but we reeeeaaallly need sparc's help over on bug 605724 so that I can finally get rid of the old nagios-3.x version.

[Comment 2 Thomas Deutschmann (RETIRED) 2017-08-18 15:32:14 UTC]

@ Arches,

please test and mark stable:

  =net-analyzer/nagios-4.3.3
  =net-analyzer/nagios-core-4.3.3

[Comment 3 Matt Turner 2017-08-31 15:22:13 UTC]

alpha stable

[Comment 4 Sergei Trofimovich (RETIRED) 2017-09-07 21:03:40 UTC]

sparc stable (thanks to Dakon)

[Comment 5 Sergei Trofimovich (RETIRED) 2017-09-24 11:01:33 UTC]

ppc64 stable

[Comment 6 Sergei Trofimovich (RETIRED) 2017-09-24 19:51:06 UTC]

ppc stable

[Comment 7 Thomas Deutschmann (RETIRED) 2017-10-03 00:43:28 UTC]

x86 stable

[Comment 8 Sergei Trofimovich (RETIRED) 2017-10-13 09:44:43 UTC]

hppa stable

[Comment 9 Aaron Bauman (RETIRED) 2017-10-13 22:59:01 UTC]

amd64 stable

[Comment 10 GLSAMaker/CVETool Bot 2017-10-18 01:18:52 UTC]

This issue was resolved and addressed in
 GLSA 201710-20 at https://security.gentoo.org/glsa/201710-20
by GLSA coordinator Aaron Bauman (b-man).

[Comment 11 Aaron Bauman (RETIRED) 2017-10-18 01:19:23 UTC]

re-opened for cleanup.

[Comment 12 Larry the Git Cow 2017-11-04 23:40:14 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8a6c86311831919c79c94f0b4744e05691fe5045

commit 8a6c86311831919c79c94f0b4744e05691fe5045
Author:     Michael Orlitzky <[e-mail]>
AuthorDate: 2017-11-02 16:33:39 +0000
Commit:     Michael Orlitzky <[e-mail]>
CommitDate: 2017-11-04 23:37:20 +0000

    net-analyzer/pnp4nagios: new revision to fix nagios/icinga "or" dependency.
    
    Previous revisions of pnp4nagios have an "or" dependency on either
    Nagios or Icinga,
    
      || ( net-analyzer/nagios-core net-analyzer/icinga ...
    
    The way "or" dependencies work is that they are considered satisfied
    if any elements of the associated group are installed. Thus the above
    stanza allows Nagios and Icinga to be swapped out without rebuilding
    pnp4nagios. That is incorrect, since later in the ebuild, nagios-
    or icinga-specific paths are compiled into pnp4nagios.
    
    The usual solution to that problem is to choose a default package that
    satisfies the "one of these" dependency, but to allow the user to
    specify one with a USE flag. This new revision adds three USE flags:
    icinga, icinga2, and nagios. The "nagios" flag is enabled by default,
    and builds pnp4nagios against net-analyzer/nagios. The other flags
    build against the associated package.
    
    In the process, the dependency on nagios-3.x was loosened to accept
    nagios-4.x as well. The nagios-3.x series has been end-of-life'd, and
    has multiple open security bugs.
    
    Bug: https://bugs.gentoo.org/628086
    Bug: https://bugs.gentoo.org/629380
    Bug: https://bugs.gentoo.org/636234
    Closes: https://bugs.gentoo.org/600424
    Package-Manager: Portage-2.3.8, Repoman-2.3.3

 net-analyzer/pnp4nagios/metadata.xml               | 16 ++++++++++++++
 ...s-0.6.26.ebuild => pnp4nagios-0.6.26-r1.ebuild} | 25 ++++++++++++++--------
 2 files changed, 32 insertions(+), 9 deletions(-)}

[Comment 13 Michael Boyle 2018-06-17 03:08:18 UTC]

@maintainer(s), please drop vulnerable.
Michael Boyle
Security Padawan

[Comment 14 Larry the Git Cow 2018-06-19 22:43:55 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8912285b30dc5dcf76d10a7810444ef69ae8e760

commit 8912285b30dc5dcf76d10a7810444ef69ae8e760
Author:     Michael Orlitzky <[e-mail]>
AuthorDate: 2018-06-19 22:32:18 +0000
Commit:     Michael Orlitzky <[e-mail]>
CommitDate: 2018-06-19 22:41:53 +0000

    net-analyzer/nagios-core: finally drop nagios-3.x from the tree.
    
    A bunch of security bugs (and my own personal happiness) were blocked
    on this because nagios-3.x was sometimes required by an old version of
    net-analyzer/pnp4nagios. Now that a version of pnp4nagios has been
    stabilized with more reasonable dependencies, we can finally get rid
    of nagios-3.x.
    
    This leaves a bunch of unused files in FILESDIR that I'll clean up in
    another commit.
    
    Bug: https://bugs.gentoo.org/636234
    Bug: https://bugs.gentoo.org/628086
    Bug: https://bugs.gentoo.org/629380
    Package-Manager: Portage-2.3.40, Repoman-2.3.9

 net-analyzer/nagios-core/Manifest                 |   1 -
 net-analyzer/nagios-core/nagios-core-3.5.1.ebuild | 216 ----------------------
 2 files changed, 217 deletions(-)