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
Partial privilege escalation via PID file manipulation #5991
Comments
|
Not as simple as one might hope, we have to be able to modify the PID file in our forked instances. |
|
That won't work because we can't rely on how other processes handle SIGUSR2. |
|
We do the same with SIGHUP, will need to extend |
The icinga2 daemon creates its PID file after dropping privileges to the
ICINGA2_USER. That may be exploited through the init script (or other management tools) by theICINGA2_USERto kill root processes, since when the daemon is stopped, root sends a "kill" signal to the contents of the PID file (which are under the control of the runtime user).For example,
However, the init script (
icinga2.init.d.cmake) is executed as root, and does,If the daemon is in any way compromised, the
ICINGA2_USERcan write a PID of his choice into his own PID file. The next time the icinga2 service is stopped, his desired PID will be killed. That can be abused to kill off sshd, to reboot the machine, etc.The "easy" way to work around this problem is to create the PID file as root, before dropping privileges. That comes with its own set of problems, in particular that you won't be able to modify or delete the PID file in the forked (non-root) process. It does however allow a very dumb, portable, init script to handle the PID file safely.
The text was updated successfully, but these errors were encountered: