[Date Prev][Date Next]
Re: (ITS#8703) slapd should create its PID file before dropping privileges
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8703) slapd should create its PID file before dropping privileges
- From: firstname.lastname@example.org
- Date: Wed, 06 Sep 2017 12:29:20 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> 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.
> 4. 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.
> 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
> slapd.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.
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.
> 7. 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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/