New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Root privilege escalation via insecure executable/config permissions (CVE-2017-14312) #424

Open
orlitzky opened this Issue Aug 30, 2017 · 19 comments

Comments

Projects
None yet
6 participants
@orlitzky
Contributor

orlitzky commented Aug 30, 2017

This is still a work-in-progress; our Nagios installation is pretty simple so I'll have to do some testing to make sure none of my proposed solutions break things.

Problem

When Nagios is configured, the user and group under which it will run are chosen:

  --with-nagios-user=<user>
                          sets user name to run nagios
  --with-nagios-group=<grp>
                          sets group name to run nagios

Both default to "nagios" -- the following is from configure.ac:

AC_ARG_WITH(nagios_user,AC_HELP_STRING([--with-nagios-user=<user>],[sets user name to run nagios]),nagios_user=$withval,nagios_user=nagios)
AC_ARG_WITH(nagios_group,AC_HELP_STRING([--with-nagios-group=<grp>],[sets group name to run nagios]),nagios_grp=$withval,nagios_grp=nagios)

Immediately after those two lines, this appears:

INSTALL_OPTS="-o $nagios_user -g $nagios_grp"
AC_SUBST(INSTALL_OPTS)

Those INSTALL_OPTS are then used in every invocation of the install command during installation.

This can lead to a root exploit in at least two ways. The fundamental problem is that the nagios daemon is intended to be launched as root, but the daemon itself and some critical configuration files are writable (in an exploitable way) by the restricted nagios user.

  1. The binary for the daemon itself, i.e. /usr/sbin/nagios is owned by the $nagios_user, but will be run as root. The $nagios_user can overwrite that binary with whatever he wants, and root will run it.

  2. The configuration file nagios.cfg specifies the user and group that nagios will run as, but is owned by that same $nagios_user. He can edit nagios.cfg himself, and set nagios_user=root, nagios_group=root. The command definition file objects/commands.cfg is also owned by $nagios_user, and he can place whatever commands in there he likes. Considering that the daemon will run as root the next time it is launched, this will also let the $nagios_user gain root eventually.

Resolution

At the very least, nagios.cfg and the executables must not be writable by anyone other than root. To ensure that the executables aren't owned by the nagios user, it suffices to set INSTALL_OPTS="" in base/Makefile.in and cgi/Makefile.in.

For the configuration file, I'm not so sure: is there a reason for the other configs (besides nagios.cfg) to be owned by the $nagios_user and $nagios_grp?

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Aug 30, 2017

Contributor

I'm going to commit a masked version to gentoo and ask for help testing. My own limited testing has shown that most things continue to work if I run the following makefile targets with empty INSTALL_OPTS:

  • (base) install-unstripped
  • install-config
  • (cgi) install-unstripped
  • install-html / install-classicui

For us, that's everything that we run except install-basic. The INSTALL_OPTS actually are used in install-basic, but even there, a little over-zealously: they give ownership of the libexecdir to the nagios user.

After we run all of those install targets, there are a few things to fix up:

  • The nagios (and nagiostats?) executable needs to be made mode 775 (currently: 770) to prevent an access denied error.
  • The owner of the libexecdir needs to be set back to root:root.

Aside from that, I was able to start up the daemon and run the web interface.

Back to testing...

Contributor

orlitzky commented Aug 30, 2017

I'm going to commit a masked version to gentoo and ask for help testing. My own limited testing has shown that most things continue to work if I run the following makefile targets with empty INSTALL_OPTS:

  • (base) install-unstripped
  • install-config
  • (cgi) install-unstripped
  • install-html / install-classicui

For us, that's everything that we run except install-basic. The INSTALL_OPTS actually are used in install-basic, but even there, a little over-zealously: they give ownership of the libexecdir to the nagios user.

After we run all of those install targets, there are a few things to fix up:

  • The nagios (and nagiostats?) executable needs to be made mode 775 (currently: 770) to prevent an access denied error.
  • The owner of the libexecdir needs to be set back to root:root.

Aside from that, I was able to start up the daemon and run the web interface.

Back to testing...

@hedenface

This comment has been minimized.

Show comment
Hide comment
@hedenface

hedenface Sep 11, 2017

Member

The only reason that's standing out at the moment for the configs to be owned by the specified user and group is that a lot of systems use those particular users/groups as the users and groups who own the configs! In the case of the group - you give specific users group access and then they are your monitoring team - they do not need root in order to update the configuration.

Also, there are a few third party utilities that rely on the configs being writable by the user they run as. It is not uncommon to add the apache user to the nagios group to allow another web UI to adjust the configuration.

Regardless - I look forward to your test results. If you'd post a link to the source here I wouldn't mind taking a look as well.

Member

hedenface commented Sep 11, 2017

The only reason that's standing out at the moment for the configs to be owned by the specified user and group is that a lot of systems use those particular users/groups as the users and groups who own the configs! In the case of the group - you give specific users group access and then they are your monitoring team - they do not need root in order to update the configuration.

Also, there are a few third party utilities that rely on the configs being writable by the user they run as. It is not uncommon to add the apache user to the nagios group to allow another web UI to adjust the configuration.

Regardless - I look forward to your test results. If you'd post a link to the source here I wouldn't mind taking a look as well.

@hedenface hedenface self-assigned this Sep 11, 2017

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Sep 11, 2017

Contributor

Everything works fine on our installation. I removed INSTALL_OPTS from every make invocation except make install-basic. After install-basic runs, I've changed the ownership of the plugin directory back to root:root.

I haven't modified the source to accomplish any of that -- I'm just running INSTALL_OPTS="" make ... in our ebuild.

To have non-root users update the configuration is a legitimate use case, but the group that nagios runs as must be different from the group that can update the configuration. Otherwise, "nagios" can just upgrade himself to root. And I don't think there's a legitimate case to have the nagios user own anything at all except the stuff he creates under e.g. /var/lib/nagios.

Our Gentoo bug is here:

https://bugs.gentoo.org/show_bug.cgi?id=629380

Since everyone is running nagios as nagios:nagios already, the least-intrusive way to fix this is probably going to involve a new group for the config files (we don't want to change the meaning of the "nagios" user and group on people):

  1. Figure out where we can use empty INSTALL_OPTS in the Makefile to prevent the nagios runtime user and group from owning anything that he doesn't need to write to while running.
  2. Add and document a new ./configure option for--with-config-group.
  3. Update the makefile to set the group on the configs to the value of $with_config_group. Then if anyone needs to be able modify the configuration, he can safely be added to this group.
  4. Throw an error if anyone tries to use the same group for --with-config-group and --with-nagios-group.
  5. Would be nice: throw an error if the --with-nagios-user is a member of the --with-config-group, or simply throw an error during startup if the nagios user can write to the config file.

Basically I would try to fix the immediate problem in (1), and then work on adding back the ability to have a "configuration editor" group in (2) through (5).

Contributor

orlitzky commented Sep 11, 2017

Everything works fine on our installation. I removed INSTALL_OPTS from every make invocation except make install-basic. After install-basic runs, I've changed the ownership of the plugin directory back to root:root.

I haven't modified the source to accomplish any of that -- I'm just running INSTALL_OPTS="" make ... in our ebuild.

To have non-root users update the configuration is a legitimate use case, but the group that nagios runs as must be different from the group that can update the configuration. Otherwise, "nagios" can just upgrade himself to root. And I don't think there's a legitimate case to have the nagios user own anything at all except the stuff he creates under e.g. /var/lib/nagios.

Our Gentoo bug is here:

https://bugs.gentoo.org/show_bug.cgi?id=629380

Since everyone is running nagios as nagios:nagios already, the least-intrusive way to fix this is probably going to involve a new group for the config files (we don't want to change the meaning of the "nagios" user and group on people):

  1. Figure out where we can use empty INSTALL_OPTS in the Makefile to prevent the nagios runtime user and group from owning anything that he doesn't need to write to while running.
  2. Add and document a new ./configure option for--with-config-group.
  3. Update the makefile to set the group on the configs to the value of $with_config_group. Then if anyone needs to be able modify the configuration, he can safely be added to this group.
  4. Throw an error if anyone tries to use the same group for --with-config-group and --with-nagios-group.
  5. Would be nice: throw an error if the --with-nagios-user is a member of the --with-config-group, or simply throw an error during startup if the nagios user can write to the config file.

Basically I would try to fix the immediate problem in (1), and then work on adding back the ability to have a "configuration editor" group in (2) through (5).

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Sep 11, 2017

Contributor

In the case of the group - you give specific users group access and then they are your monitoring team - they do not need root in order to update the configuration.

I was just thinking about this in the shower (where all good work gets done) and even in the intended use case, this allows anyone in the nagios group to gain root. If your web server can edit the nagios config files, he can set nagios_user=root and then place whatever command he wants in one of the service checks. Then any web UI exploit becomes a root exploit on the machine, and the same thing goes for any other member of the nagios group. If you want to let a group of non-root users edit the configs, you can't do it safely, because they can always gain root in that manner.

So, I amend my previous comment -- I don't know what to do about that. Would it be safe if nagios.cfg remained root:root but if the other configs were editable?

Contributor

orlitzky commented Sep 11, 2017

In the case of the group - you give specific users group access and then they are your monitoring team - they do not need root in order to update the configuration.

I was just thinking about this in the shower (where all good work gets done) and even in the intended use case, this allows anyone in the nagios group to gain root. If your web server can edit the nagios config files, he can set nagios_user=root and then place whatever command he wants in one of the service checks. Then any web UI exploit becomes a root exploit on the machine, and the same thing goes for any other member of the nagios group. If you want to let a group of non-root users edit the configs, you can't do it safely, because they can always gain root in that manner.

So, I amend my previous comment -- I don't know what to do about that. Would it be safe if nagios.cfg remained root:root but if the other configs were editable?

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Sep 11, 2017

Contributor

Would it be safe if nagios.cfg remained root:root but if the other configs were editable?

The obvious problem with that solution doesn't seem to be a problem: if I try to set nagios_user or nagios_group in one of the files under cfg_dir, nagios tells me it's an invalid statement. So maybe that plan above can still work so long as we ensure that nagios.cfg is root:root.

Contributor

orlitzky commented Sep 11, 2017

Would it be safe if nagios.cfg remained root:root but if the other configs were editable?

The obvious problem with that solution doesn't seem to be a problem: if I try to set nagios_user or nagios_group in one of the files under cfg_dir, nagios tells me it's an invalid statement. So maybe that plan above can still work so long as we ensure that nagios.cfg is root:root.

@box293

This comment has been minimized.

Show comment
Hide comment
@box293

box293 Sep 11, 2017

Contributor

There are use cases like in Nagios XI where the Core Configuration Manager allows you to edit nagios.cfg and hence apache would need to save changes to the file.

Contributor

box293 commented Sep 11, 2017

There are use cases like in Nagios XI where the Core Configuration Manager allows you to edit nagios.cfg and hence apache would need to save changes to the file.

@orlitzky orlitzky changed the title from Root privilege escalation via insecure executable/config permissions to Root privilege escalation via insecure executable/config permissions (CVE-2017-14312) Sep 11, 2017

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Sep 11, 2017

Contributor

@box293

crap =(

I think it's pretty clear now how any non-root user who can edit nagios.cfg can easily gain root. I'm not familiar with Nagios XI, but someone who is will have to evaluate the impact of this on it and similar products that expect to be able to write to nagios.cfg.

  • Can they live without that ability?
  • Should we give up the charade, and ask those people to run their web servers as root if they require that ability?
  • Should the nagios_user and nagios_group parameters be removed from the configuration file, and made command-line-only options? If we did the same thing with the lock_file parameter and everything else that gets used while the daemon is still root, then we could make it so that nagios.cfg is read after dropping privileges. Then it doesn't matter who can edit the file.

I know the first two are bad, and the third is a lot of work -- I'm just throwing stuff out as it comes to mind.

Contributor

orlitzky commented Sep 11, 2017

@box293

crap =(

I think it's pretty clear now how any non-root user who can edit nagios.cfg can easily gain root. I'm not familiar with Nagios XI, but someone who is will have to evaluate the impact of this on it and similar products that expect to be able to write to nagios.cfg.

  • Can they live without that ability?
  • Should we give up the charade, and ask those people to run their web servers as root if they require that ability?
  • Should the nagios_user and nagios_group parameters be removed from the configuration file, and made command-line-only options? If we did the same thing with the lock_file parameter and everything else that gets used while the daemon is still root, then we could make it so that nagios.cfg is read after dropping privileges. Then it doesn't matter who can edit the file.

I know the first two are bad, and the third is a lot of work -- I'm just throwing stuff out as it comes to mind.

@hedenface

This comment has been minimized.

Show comment
Hide comment
@hedenface

hedenface Sep 11, 2017

Member
Member

hedenface commented Sep 11, 2017

@ZZS2017

This comment has been minimized.

Show comment
Hide comment
@ZZS2017

ZZS2017 Sep 12, 2017

Now. It's fixed?

ZZS2017 commented Sep 12, 2017

Now. It's fixed?

@rakesh-patnaik

This comment has been minimized.

Show comment
Hide comment
@rakesh-patnaik

rakesh-patnaik Oct 19, 2017

I am wondering if this is a issue in my install. I have nagios3 running as nagios user. Particularly this statement "The fundamental problem is that the nagios daemon is intended to be launched as root" - this is not true in my install of nagios core 3.5.1 . Can someone please explain the above quoted statement?

here is a output of the nagios process running in the system:
ps -ef | grep nagios3
nagios 20342 1 1 10:25 ? 00:00:00 /usr/sbin/nagios3 -d /etc/nagios3/nagios.cfg

rakesh-patnaik commented Oct 19, 2017

I am wondering if this is a issue in my install. I have nagios3 running as nagios user. Particularly this statement "The fundamental problem is that the nagios daemon is intended to be launched as root" - this is not true in my install of nagios core 3.5.1 . Can someone please explain the above quoted statement?

here is a output of the nagios process running in the system:
ps -ef | grep nagios3
nagios 20342 1 1 10:25 ? 00:00:00 /usr/sbin/nagios3 -d /etc/nagios3/nagios.cfg

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Oct 19, 2017

Contributor

@rakesh-patnaik your ps command shows that nagios is running as the "nagios" user, but doesn't say who the command was originally launched as. It was probably launched as root, and then later dropped privileges to the "nagios" user. How do you start the daemon?

Contributor

orlitzky commented Oct 19, 2017

@rakesh-patnaik your ps command shows that nagios is running as the "nagios" user, but doesn't say who the command was originally launched as. It was probably launched as root, and then later dropped privileges to the "nagios" user. How do you start the daemon?

@rakesh-patnaik

This comment has been minimized.

Show comment
Hide comment
@rakesh-patnaik

rakesh-patnaik Oct 19, 2017

we use the SysV init to start nagios3.
sudo -u nagios bash -c "service nagios3 start"
we have automation tools that perform the above start procedure.

rakesh-patnaik commented Oct 19, 2017

we use the SysV init to start nagios3.
sudo -u nagios bash -c "service nagios3 start"
we have automation tools that perform the above start procedure.

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Oct 19, 2017

Contributor

@rakesh-patnaik

sudo -u nagios bash -c "service nagios3 start"

Then you're safe from this, since you're using sudo to drop privileges before the daemon even starts. Just be sure you never execute /usr/sbin/nagios3 as root!

Most people would just add the "nagios3" service to the default run level, and that's who this vulnerability affects.

Contributor

orlitzky commented Oct 19, 2017

@rakesh-patnaik

sudo -u nagios bash -c "service nagios3 start"

Then you're safe from this, since you're using sudo to drop privileges before the daemon even starts. Just be sure you never execute /usr/sbin/nagios3 as root!

Most people would just add the "nagios3" service to the default run level, and that's who this vulnerability affects.

@rakesh-patnaik

This comment has been minimized.

Show comment
Hide comment
@rakesh-patnaik

rakesh-patnaik Oct 19, 2017

@orlitzky thanks for the clarification. appreciate your bringing this issue to attention and resolving it for those affected.

rakesh-patnaik commented Oct 19, 2017

@orlitzky thanks for the clarification. appreciate your bringing this issue to attention and resolving it for those affected.

@exolain

This comment has been minimized.

Show comment
Hide comment
@exolain

exolain Jun 15, 2018

Is there going to be a new nagios version once this issue is closed?

exolain commented Jun 15, 2018

Is there going to be a new nagios version once this issue is closed?

@hedenface

This comment has been minimized.

Show comment
Hide comment
@hedenface

hedenface Jun 15, 2018

Member

Yes. 4.4.0 contains the fix. It was actually going to be released yesterday, but I've gotten tied up in other things. I'm anticipating releasing it Monday, as long as there are no blocking breakages discovered from now until then :)

Member

hedenface commented Jun 15, 2018

Yes. 4.4.0 contains the fix. It was actually going to be released yesterday, but I've gotten tied up in other things. I'm anticipating releasing it Monday, as long as there are no blocking breakages discovered from now until then :)

@hedenface

This comment has been minimized.

Show comment
Hide comment
@hedenface

hedenface Jun 15, 2018

Member

Nope. Ignore me. For some reason I thought this was a different issue. I'll take another look at this, as it's fallen off of the radar for a bit.

Member

hedenface commented Jun 15, 2018

Nope. Ignore me. For some reason I thought this was a different issue. I'll take another look at this, as it's fallen off of the radar for a bit.

@hedenface

This comment has been minimized.

Show comment
Hide comment
@hedenface

hedenface Jun 15, 2018

Member

Okay, so re-reading it, I have a bit of information regarding the issue.

We'll add a configure group (which will likely default to the specified nagios group [so as to avoid breaking backwards compatibility where possible]) and a configure user - but this won't be done until a major release. I'll add it to Core 5 for now, as it isn't so much work as to not make it in that release.

There have already been quite a lot of "breaking changes" released in in the last two enhancement/minor versions, I'd like that to stop where possible. By allowing configure flags to overwrite default behavior, the packagers for different distributions can use them as they see fit.

@orlitzky How does this sound as an actual achievable goal?

Member

hedenface commented Jun 15, 2018

Okay, so re-reading it, I have a bit of information regarding the issue.

We'll add a configure group (which will likely default to the specified nagios group [so as to avoid breaking backwards compatibility where possible]) and a configure user - but this won't be done until a major release. I'll add it to Core 5 for now, as it isn't so much work as to not make it in that release.

There have already been quite a lot of "breaking changes" released in in the last two enhancement/minor versions, I'd like that to stop where possible. By allowing configure flags to overwrite default behavior, the packagers for different distributions can use them as they see fit.

@orlitzky How does this sound as an actual achievable goal?

@hedenface hedenface added this to the 5.0.0 milestone Jun 15, 2018

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Jun 17, 2018

Contributor

The timeline is fine, but the devil is in the details with regards to the implementation. Adding another user/group doesn't help if they can still edit the configuration file to say e.g. nagios_user = root and then place bad commands in there. The plan from #424 (comment) should work and I'm happy to look at the changes once you have something concrete. I think it's a big enough change to go in 5.0.0.

Contributor

orlitzky commented Jun 17, 2018

The timeline is fine, but the devil is in the details with regards to the implementation. Adding another user/group doesn't help if they can still edit the configuration file to say e.g. nagios_user = root and then place bad commands in there. The plan from #424 (comment) should work and I'm happy to look at the changes once you have something concrete. I think it's a big enough change to go in 5.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment