michael@orlitzky.com wrote:
On 09/05/2017 05:38 PM, Ryan Tandy wrote:
If you would like to propose a patch, we could review that. For myself I don't think I would attach a high priority to this.
I understand that it's a low priority, I'm just trying to clean up the hundred or so cases of this that we have in Gentoo. In a few, it's impossible to do so because of the way the daemon creates the PID file (like it is here), so I'm doing bugs/CVEs to keep track of them. This way that distribution maintainers have something to watch and will know when they can fix their init scripts.
Your problem scenario is still unrealistic.
- Someone compromises the daemon, which sits on the open network.
Nobody compromises slapd from the network. There are no buffer overflow vulnerabilities, there are no RCE vulnerabilities.
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 slapd.pid file, and he does.
I run "/etc/init.d/slapd stop" to stop the daemon while I investigate the weird behavior resulting from the hack.
Even if that were possible, it's clearly a bug in the init script, which failed to check that the process with that PID was the process it was expecting to find. Note that this is something any init script needs to do anyway, since PID files can go stale and some other process may be using the PID by the time you reference the file.
- Oops, the machine reboots, because I killed PID 1.
Big deal, you caused a temporary service outage. No remote code was injected, no data was leaked, no actual lasting damage was done.
I'm inclined to close this ticket. It presupposes a class of bug that doesn't exist in OpenLDAP code, and it relies on an additional bug in a script that isn't part of OpenLDAP code. At best, this ticket has been mis-filed and the submitter needs to submit it to somewhere relevant, like whoever authored the broken init script.