CVE-2017-14159 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14159): slapd in OpenLDAP 2.4.45 and earlier 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. References: http://www.openldap.org/its/index.cgi?findid=8703
Upstream's position on this is that it's not a problem, because (quoting) Nobody compromises slapd from the network. There are no buffer overflow vulnerabilities, there are no RCE vulnerabilities. *shrug* You'll have to try to work around it in the init script. You can get the user of the process whose PID you find in the file with ps -p <pid> -o user= and you can get the name of the command with ps -p <pid> -o comm= If you check those against the expected values every time you send a signal, it's a lot safer. The most an attacker can do in that case is prevent you from killing his hacked process via the init script.
> See Also: https://bugs.gentoo.org/show_bug.cgi?id=767184 But I was told that slapd has no vulnerabilities. I wish you could see the face I'm making.
According to https://nvd.nist.gov/vuln/detail/CVE-2017-14159#range-8035897 only versions up to 2.4.45 are affected. The lowest version in portage is 2.4.57. I assume correctly that this issue could be closed now?
(In reply to Dennis Lamm from comment #3) > According to https://nvd.nist.gov/vuln/detail/CVE-2017-14159#range-8035897 > only versions up to 2.4.45 are affected. > > The lowest version in portage is 2.4.57. I assume correctly that this issue > could be closed now? 2.4.45 was the latest version when I reported the bug, but it still exists. I guess slapd now supports running in the foreground, to support systemd? If so, you could probably work around the issue in OpenRC relatively easily, by running slapd in the foreground and then using command_background=true to tell OpenRC to background the process itself. The way OpenRC does it is secure. That approach is covered (indirectly) in, https://github.com/OpenRC/openrc/blob/master/service-script-guide.md where the discussion is focused on daemons that don't know how to background themselves. But if you think of it as "daemons that don't know how to background themselves SECURELY", item 2 in the "Don't write your own start/stop functions" applies.
(In reply to Dennis Lamm from comment #3) > According to https://nvd.nist.gov/vuln/detail/CVE-2017-14159#range-8035897 > only versions up to 2.4.45 are affected. > > The lowest version in portage is 2.4.57. I assume correctly that this issue > could be closed now? No, CVEs aren't really trustworthy for anything. Rely instead on referenced upstream patches if there are any.
