[<prev] [next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
