michael orlitzky

CVE-2018-6536: Icinga2 privilege escalation via PID file manipulation

posted 2018-04-15

Versions affected
2.8.1 and earlier
Published on
Fixed in
commit c6b8668 , version 2.8.2
Bug report


The icinga2 daemon creates its PID file after dropping privileges to a non-root user. That may be exploited by the unprivileged user to kill root processes, since when the daemon is stopped via its init script, root sends a SIGINT to the contents of the PID file (which are under the control of the runtime user).


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 signaled (many daemons reload their configurations in response to a SIGHUP). To fulfil 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.

This is commonly exploitable through init scripts that are run as root and which blindly trust the contents of their PID files. The icinga2 package ships such an init script as etc/initsystem/icinga2.init.d.cmake, containing the (slightly edited) function:

stop() {
  printf "Stopping Icinga 2: "

  # Boring stuff removed

  pid=`cat $ICINGA2_PID_FILE`

  if kill -INT $pid >/dev/null 2>&1; then
    for i in 1 2 3 4 5 6 7 8 9 10; do
      if ! kill -CHLD $pid >/dev/null 2>&1; then

      printf '.'

      sleep 3

  if kill -CHLD $pid >/dev/null 2>&1; then
    kill -KILL $pid

  echo "Done"

The PID is obtained from the untrusted $ICINGA2_PID_FILE, after which a SIGINT is sent to it as root.


An example exploit involving an init script is,

  1. I run /etc/init.d/icinga2 start to start the daemon.
  2. icinga2 drops to the icinga user.
  3. icinga2 writes its PID file, now owned by the icinga user.
  4. Someone compromises the daemon, which sits on the network.
  5. The attacker is generally limited in what he can do because the daemon doesn't run as root. However, he can write “1” into the PID file, and he does.
  6. I run /etc/init.d/icinga2 stop to stop the daemon while I investigate the weird behavior resulting from the hack.
  7. The machine reboots, because I killed PID 1 (this is normally restricted to root).


The icinga2 program gained a new power, icinga2 internal signal, that will send a signal as its unprivileged runtime user. This new ability is used in the init script whenever a signal is sent.