Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Root privilege escalation via insecure permissions (CVE-2017-16882) #1601
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:
and likewise with the config files -- at least the following are vulnerable:
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
My personal instinct would be to drop the
changed the title from
Root privilege escalation via insecure permissions
Root privilege escalation via insecure permissions (CVE-2017-16882)
Nov 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.