posted 2017-08-14
Nagios 4.3.2 and earlier creates a PID file after dropping privileges to a non-root account. This is exploitable by that non-root account to kill root processes, because the init script supplied by Nagios (and many distributions) will send a SIGTERM to the contents of the PID file upon stopping the service.
The purpose of the PID file is to hold the PID of the running daemon, so that later it can be stopped, restarted, or otherwise signalled (many daemons reload their configurations in response to a SIGHUP). To fulfill that purpose, the contents of the PID file need to be trustworthy. If the PID file is writable by a non-root user, then he can replace its contents with the PID of a root process. Afterwards, any attempt to signal the PID contained in the PID file will instead signal a root process chosen by the non-root user (a vulnerability).
This is commonly exploitable by init scripts that are run as root and which blindly trust the contents of their PID files. Nagios itself ships such an init script, daemon-init.in, so the risk is not theoretical in this case.
An example scenario involving an init script would be,
/etc/init.d/nagios start
to start the daemon.
/etc/init.d/nagios stop
to stop the daemon while I
investigate the weird behavior resulting from the hack.
The problem is avoided by creating the PID file as root, before dropping privileges. Init script writers and distribution packagers should relocate the PID file to /run or a similar root-owned directory.