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-16882) #1601

Closed
orlitzky opened this Issue Nov 18, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@orlitzky

orlitzky commented Nov 18, 2017

Hello,

Unfortunately icinga-core has the same problem with its installed permissions that nagios-core has, reported in NagiosEnterprises/nagioscore#424. The following executables are installed owned by the icinga user:

  • bin/icinga
  • bin/icingastats
  • bin/ido2db
  • bin/log2ido

and likewise with the config files -- at least the following are vulnerable:

  • etc/icinga.cfg
  • etc/ido2db.cfg-sample (yeah, it's a sample, but better safe than sorry)

The executables are exploitable because icinga can edit them and root will run them; the configs are vulnerable because icinga can edit them to give the daemons instructions and then insist that those daemons run as root.

The good news for you, potentially, is that maybe you don't care about maintaining compatibility with Nagios XI, and can set icinga.cfg to root:root.

My personal instinct would be to drop the INSTALL_OPTS all around, and then give the icinga user write permission only on those directories it needs. If somebody wants to manage the configs other than icinga.cfg with a dedicated, non-icinga group -- then he could do that either on his own or potentially with a new --with-config-group flag.

@carnil

This comment has been minimized.

Show comment
Hide comment
@carnil

carnil Nov 18, 2017

This issue has been assigned CVE-2017-16882

carnil commented Nov 18, 2017

This issue has been assigned CVE-2017-16882

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

@dnsmichi dnsmichi added this to the 1.14.1 milestone Dec 19, 2017

@dnsmichi

This comment has been minimized.

Show comment
Hide comment
@dnsmichi

dnsmichi Dec 19, 2017

Member

Sorry for the delayed answer, it took me while to understand why and how to resolve this one. 1.x has a lower priority to me than 2.x these days.

It only affects source installations as far as I can see, packagers normally apply their own permissions.

The spec file e.g. defines INSTALL_OPTS='' and sets proper permissions to root,root and only allows for runtime directories. Debian does it in the same manner afaik.

I don't mind purging away INSTALL_OPTS anywhere suitable. Users who may depend on the permissions are not forced to upgrade anyways. 1.x is EOL and only collects security and minor patches.

I also guess 1.14.1 will be last one for the 1.x branch.

Member

dnsmichi commented Dec 19, 2017

Sorry for the delayed answer, it took me while to understand why and how to resolve this one. 1.x has a lower priority to me than 2.x these days.

It only affects source installations as far as I can see, packagers normally apply their own permissions.

The spec file e.g. defines INSTALL_OPTS='' and sets proper permissions to root,root and only allows for runtime directories. Debian does it in the same manner afaik.

I don't mind purging away INSTALL_OPTS anywhere suitable. Users who may depend on the permissions are not forced to upgrade anyways. 1.x is EOL and only collects security and minor patches.

I also guess 1.14.1 will be last one for the 1.x branch.

dnsmichi added a commit that referenced this issue Dec 19, 2017

Fix source installation permissions (owner root instead of icinga)
This fixes CVE-2017-16882

Packages are not affected, they always set INSTALL_OPTS='' and use
their own safe permissions.

refs #1601

dnsmichi added a commit that referenced this issue Dec 19, 2017

Fix source installation permissions (owner root instead of icinga)
This fixes CVE-2017-16882

Packages are not affected, they always set INSTALL_OPTS='' and use
their own safe permissions.

refs #1601
@orlitzky

This comment has been minimized.

Show comment
Hide comment
@orlitzky

orlitzky Dec 19, 2017

Thanks, this mostly look good. While testing HEAD, I found two other things that I think you should look at, but I'll open separate issues for them.

orlitzky commented Dec 19, 2017

Thanks, this mostly look good. While testing HEAD, I found two other things that I think you should look at, but I'll open separate issues for them.

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