(We'll need a separate bug for icinga after this) tl;dr the "nagios" user owns some problematic files. First, he owns /usr/sbin/nagios, which is run as root every time you start the nagios service. Not much imagination is needed to gain root through that. But he also owns /etc/nagios/nagios.cfg, the main configuration file for the daemon, and all of the service, host, command etc. files under /etc/nagios/objects. Since the "nagios" user owns nagios.cfg, he can put something evil in one of the service checks, and then write nagios_user=root and nagios_group=root into nagios.cfg. The next time the service starts, he'll get root that way too. I'm working on fixing this and will try to get it done upstream (see $URL). My biggest problem is that I'm not a very heavy user of nagios. I've committed a masked nagios-core-4.3.4 that puts most things back to root:root. This works in a default install, and works at my office where we monitor our own servers and our customers, but neither of those do anything fancy. If any of you have complicated setups or friends who do, can you please ask them to give nagios-core-4.3.4 a try? Once I know what files it's safe to chown back to root:root, I'll submit a pull request upstream to leave them that way in the first place. I'll handle the CVE once the fix is nailed down, too.
No problems found after updating to 4.3.4.
(In reply to Tomáš Mózes from comment #1) > No problems found after updating to 4.3.4. Can you check the permissions on /etc/nagios and the files under there? They should all be root:root, but I think during an upgrade, the old ownership will be left in-tact. If you have a way to re-deploy your nagios config, an uninstall/reinstall may be the best way to ensure that your permissions get fixed. The big problems are /usr/sbin/nagios, and /etc/nagios/nagios.cfg, but others can probably be exploited too.
I got the CVE for this since there is an easy workaround for the problem (set everything to root:root yourself, if you don't need it otherwise). It looks like the problem may be harder to fix upstream, though. One of the contributors pointed out that the Nagios XI Core Configuration Manager expects to be able to write to nagios.cfg, which makes the workaround a no-go because it will break that and similar software. I've unmasked nagios-4.3.4 in ::gentoo anyhow, and hopefully none of our users are expecting to write to nagios.cfg. If I get a lot of complaints, I can re-mask or, or give people another bad workaround: put back the group permissions yourself, with the understanding that anyone in the group can gain root without much trouble. @security: whenever this gets sorted out, it should have a GLSA, and the GLSA needs to mention that permissions on all nagios-core files (equery f nagios-core) should be verified by hand. Otherwise upgraders will be left vulnerable. Anything that your nagios installation doesn't need to write to should be root:root. On my system that includes everything except /var/nagios and the nagios.log file.
(In reply to Michael Orlitzky from comment #2) > (In reply to Tomáš Mózes from comment #1) > > No problems found after updating to 4.3.4. > > Can you check the permissions on /etc/nagios and the files under there? They > should all be root:root, but I think during an upgrade, the old ownership > will be left in-tact. Yes, they are root:root, changed them manually. > If you have a way to re-deploy your nagios config, an uninstall/reinstall > may be the best way to ensure that your permissions get fixed. The big > problems are /usr/sbin/nagios, and /etc/nagios/nagios.cfg, but others can > probably be exploited too. It's a pity, but not yet, waiting for a new server to be forced to ansible our nagios installation.
security@, this is as fixed as it's going to get in Gentoo. The upstream fix is delayed because there are some tools that require the insecure permissions. nagios-core-4.3.4 in the tree will install with the correct permissions. However, all upgraders must follow the workaround instructions at the bottom of http://michael.orlitzky.com/cves/cve-2017-14312.xhtml namely, dirs="/bin /sbin /usr /etc" nagios_user=nagios nagios_group=nagios find $dirs -user "${nagios_user}" -print0 | \ xargs --null chown --no-dereference --from="${nagios_user}" root find $dirs -group "${nagios_group}" -print0 | \ xargs --null chown --no-dereference --from=":${nagios_group}" :0 to fix the ownership of their pre-existing stuff. In addition, on Gentoo, the permissions on /etc/nagios will need to be (further) adjusted. After fixing the ownership, the following should suffice: chown --no-dereference --from=:apache :0 /etc/nagios chown --no-dereference --from=:lighttpd :0 /etc/nagios find /etc/nagios -type d -print0 | xargs --null chmod 755 find /etc/nagios -type f -print0 | xargs --null chmod 644 Prior to nagios-core-4.3.4, the /etc/nagios directory could have its group set to either "apache" or "lighttpd" (depending on your USE flags), and those group permissions were used to allow the web server to read the nagios configuration. After the commands above, /etc/nagios should be root:0 and readable by everyone. I would additionally warn everyone to please check what they have under /etc/nagios before blindly running any of these commands. For example, someone may have stuck something sensitive in /etc/nagios relying on the fact that it was not world-readable.
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 <mjo@gentoo.org> AuthorDate: 2017-11-02 16:33:39 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> 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(-)}
@arches please stablize Michael Boyle Gentoo Security Padawan
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f1050603f504e8b20e0729c893ac6860ffb85605 commit f1050603f504e8b20e0729c893ac6860ffb85605 Author: Aaron Bauman <bman@gentoo.org> AuthorDate: 2018-04-23 03:16:31 +0000 Commit: Aaron Bauman <bman@gentoo.org> CommitDate: 2018-04-23 03:16:31 +0000 net-analyzer/nagios-core: amd64 stable wrt bug #629380 Bug: https://bugs.gentoo.org/629380 Package-Manager: Portage-2.3.31, Repoman-2.3.9 net-analyzer/nagios-core/nagios-core-4.3.4.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)}
x86 stable
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f9eeaadf74de22ee6365ffe433816aca7bc45f3 commit 4f9eeaadf74de22ee6365ffe433816aca7bc45f3 Author: Rolf Eike Beer <eike@sf-mail.de> AuthorDate: 2018-05-08 18:13:16 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-05-08 18:42:39 +0000 net-analyzer/nagios-core: stable 4.3.4 for sparc Bug: https://bugs.gentoo.org/629380 Package-Manager: Portage-2.3.24, Repoman-2.3.6 RepoMan-Options: --include-arches="sparc" net-analyzer/nagios-core/nagios-core-4.3.4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Stable on alpha.
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 <mjo@gentoo.org> AuthorDate: 2018-06-19 22:32:18 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> 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(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ae1ec1ff5e85fdcbb2ae4e5f184a5e8e01fa3038 commit ae1ec1ff5e85fdcbb2ae4e5f184a5e8e01fa3038 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-06-24 19:46:42 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-06-24 20:20:18 +0000 net-analyzer/nagios-core: stable 4.3.4 for ppc64, bug #629380 Bug: https://bugs.gentoo.org/629380 Package-Manager: Portage-2.3.40, Repoman-2.3.9 RepoMan-Options: --include-arches="ppc64" net-analyzer/nagios-core/nagios-core-4.3.4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
ppc stable
I would like to point out that nagios-4.3.4 has to be stabilized alongside nagios-core-4.3.4. Thank you!
hppa dropped
GLSA request filed.
Sorry, @maintainers, please clean 4.3.3.
(In reply to Aaron Bauman from comment #18) > Sorry, @maintainers, please clean 4.3.3. We can't yet; net-analyzer/nagios-4.3.4 needs to be stabilized first (see comment #15). Should we do that here?
(In reply to Michael Orlitzky from comment #19) > (In reply to Aaron Bauman from comment #18) > > Sorry, @maintainers, please clean 4.3.3. > > We can't yet; net-analyzer/nagios-4.3.4 needs to be stabilized first (see > comment #15). > > Should we do that here? Sure, we can call for it here... or set the proper depends if there is a stable bug for it already.
amd64 stable
sparc stable
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8a6af2aac8bbeb54d0b68e36457338697ea7a93d commit 8a6af2aac8bbeb54d0b68e36457338697ea7a93d Author: Tobias Klausmann <klausman@gentoo.org> AuthorDate: 2018-11-27 16:00:55 +0000 Commit: Tobias Klausmann <klausman@gentoo.org> CommitDate: 2018-11-27 16:00:55 +0000 net-analyzer/nagios-4.3.4-r0: alpha stable Bug: http://bugs.gentoo.org/629380 Signed-off-by: Tobias Klausmann <klausman@gentoo.org> net-analyzer/nagios/nagios-4.3.4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
ppc64 stable
This issue was resolved and addressed in GLSA 201812-03 at https://security.gentoo.org/glsa/201812-03 by GLSA coordinator Aaron Bauman (b-man).
re-opened for cleanup
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8588e32c1c4dd67e878bee70d1777b8fdb9c2662 commit 8588e32c1c4dd67e878bee70d1777b8fdb9c2662 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2018-12-02 16:00:24 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2018-12-02 16:01:33 +0000 net-analyzer/nagios-core: remove nagios-core-4.3.3 to fix CVE-2017-14312. Bug: https://bugs.gentoo.org/629380 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 net-analyzer/nagios-core/Manifest | 1 - net-analyzer/nagios-core/nagios-core-4.3.3.ebuild | 246 ---------------------- 2 files changed, 247 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fa9341fd5ca844defca217f450c091bd195dea04 commit fa9341fd5ca844defca217f450c091bd195dea04 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2018-12-02 15:58:17 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2018-12-02 16:01:32 +0000 net-analyzer/nagios: remove nagios-4.3.3 to fix CVE-2017-14312. This drops the last stable version of net-analyzer/nagios on hppa, but they've been notified on bug 629380. Bug: https://bugs.gentoo.org/629380 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 net-analyzer/nagios/nagios-4.3.3.ebuild | 15 --------------- 1 file changed, 15 deletions(-)
Thanks, Michael!
