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 permissions (CVE-2017-16834) #140

Open
orlitzky opened this Issue Nov 2, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@orlitzky

orlitzky commented Nov 2, 2017

I think pnp4nagios has the same problem as nagios-core:

NagiosEnterprises/nagioscore#424

Since the same sort of INSTALL_OPTS are used, we wind up with e.g. /etc/pnp and in particular /etc/pnp/npcd.cfg owned by the "nagios" (or "icinga", or whatever) user. However, the contents of /etc/pnp/npcd.cfg are sensitive: if the "nagios" user can edit them, he can remove,

user = nagios
group = nagios

and set

user = root
group = root

Afterwards, anything he can make npcd do, will be done as root. The fix is probably the same: I think everything under /etc/pnp should be owned by root instead of by the nagios user/group. I'm not a pnp4nagios expert, though, so there may be problems with that approach that I'm unaware of.

What happens if we just drop INSTALL_OPTS?

gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Nov 4, 2017

net-analyzer/pnp4nagios: new revision to fix insecure config permissi…
…ons.

Previous revisions of pnp4nagios install /etc/pnp owned by the "nagios
user," and the npcd daemon also runs as that user. That configuration
is insecure: the unprivileged user can edit /etc/pnp/npcd.cfg, and
escalate his own privileges by setting "user = root". To avoid the
problem, we set INSTALL_OPTS="" while running "emake install". That
leaves all of /etc/pnp with the default (root:root) ownership.

Bug: lingej/pnp4nagios#140
Package-Manager: Portage-2.3.8, Repoman-2.3.3

@orlitzky orlitzky changed the title from Root privilege escalation via insecure config permissions to Root privilege escalation via insecure permissions (CVE-2017-16834) Nov 16, 2017

@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Nov 16, 2017

Just to confirm, the same problem does exist with pnp4nagios.

In addition to the npcd.cfg issue, the npcd executable is owned by the unprivileged user but launched as root. The unprivileged user can therefore modify the npcd executable to do whatever he wants as root.

I suggest eliminating INSTALL_OPTS from the build system entirely, since most of the pnp4nagios files should be owned and writable only by root anyway. The few exceptions are,

  • The directory specified by the --with-perfdata-dir configure flag.
  • The directory specified by the --with-perfdata-spool-dir configure flag.
  • The directory containing the file specified by the --with-perfdata-logfile configure flag.
  • The STATS_DIR defined in process_perfdata.cfg.

The build system will have to be updated to make those directories writable by the runtime user if INSTALL_OPTS is dropped.

orlitzky commented Nov 16, 2017

Just to confirm, the same problem does exist with pnp4nagios.

In addition to the npcd.cfg issue, the npcd executable is owned by the unprivileged user but launched as root. The unprivileged user can therefore modify the npcd executable to do whatever he wants as root.

I suggest eliminating INSTALL_OPTS from the build system entirely, since most of the pnp4nagios files should be owned and writable only by root anyway. The few exceptions are,

  • The directory specified by the --with-perfdata-dir configure flag.
  • The directory specified by the --with-perfdata-spool-dir configure flag.
  • The directory containing the file specified by the --with-perfdata-logfile configure flag.
  • The STATS_DIR defined in process_perfdata.cfg.

The build system will have to be updated to make those directories writable by the runtime user if INSTALL_OPTS is dropped.

@lingej

This comment has been minimized.

Show comment
Hide comment
@lingej

lingej Nov 16, 2017

Owner

Thanks for your Report!

Commit 23c123f

INSTALL_OPTS is now removed for ...

  • etc/npcd.cfg
  • bin
  • bin/npcd
Owner

lingej commented Nov 16, 2017

Thanks for your Report!

Commit 23c123f

INSTALL_OPTS is now removed for ...

  • etc/npcd.cfg
  • bin
  • bin/npcd
@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Nov 16, 2017

Thank you!

In hindsight -- if it doesn't cause any problems -- it might be best to make the "libexec" executables non-writable also:

  • libexec/rrd_modify.pl
  • libexec/process_perfdata.pl
  • libexec/rrd_convert.pl
  • libexec/check_pnp_rrds.pl

The risk there (and I'm guilty of this myself) is that root might be troubleshooting an issue and run ./process_perfdata.pl --help without checking who owns the script, opening up the same sort of exploit that npcd had. 'sup to you though, thanks for fixing this.

orlitzky commented Nov 16, 2017

Thank you!

In hindsight -- if it doesn't cause any problems -- it might be best to make the "libexec" executables non-writable also:

  • libexec/rrd_modify.pl
  • libexec/process_perfdata.pl
  • libexec/rrd_convert.pl
  • libexec/check_pnp_rrds.pl

The risk there (and I'm guilty of this myself) is that root might be troubleshooting an issue and run ./process_perfdata.pl --help without checking who owns the script, opening up the same sort of exploit that npcd had. 'sup to you though, thanks for fixing this.

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