Date: Mon, 11 Sep 2017 18:00:28 -0400 From: Michael Orlitzky <michael@...itzky.com> To: oss-security@...ts.openwall.com Subject: CVE-2017-14159: OpenLDAP privilege escalation via PID file manipulation Product: OpenLDAP (slapd server) Versions-affected: all modern Bug-report: http://www.openldap.org/its/index.cgi?findid=8703 Author: Michael Orlitzky == Summary == slapd in all modern versions of OpenLDAP creates a PID file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for PID file modification before a root script executes a "kill `cat /pathname`" command, as demonstrated by openldap-initscript. == Details == 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 signalled (many daemons reload their configurations in response to a SIGHUP). To fulfill 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 (a vulnerability). This is commonly exploitable through init scripts that are run as root and which blindly trust the contents of their PID files. An example of such an init script can be found at, https://github.com/ltb-project/openldap-initscript == Exploitation == There is only a risk of exploitation when some other user relies on the data in the PID file. An example of a problematic scenario involving an init script would be, 1. I run "/etc/init.d/slapd start" to start the daemon. 2. slapd drops to the "slapd" user. 3. slapd writes its PID file, now owned by the "slapd" 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/slapd 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). == Resolution == The slapd PID file will remain owned by its unprivileged runtime user: the OpenLDAP project believes it is the responsibility of the init script to address this problem. The POSIX "ps" command can be used towards that end. You can get the user of the process whose PID you find with ps -p <pid> -o user= and you can get the name of the command with ps -p <pid> -o comm= Init script authors should check the output of those two command against the expected values before sending a signal to a running process. That will eliminate the most serious scenarios (where the attacker e.g. kills the firewall), but still leaves open the possibility that the attacker can prevent "/etc/init.d/slapd stop" from terminating his compromised process by entering junk into the PID file.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ