OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/8703
Full headers

From: michael@orlitzky.com
Subject: slapd should create its PID file before dropping privileges
Compose comment
Download message
State:
0 replies:
10 followups: 1 2 3 4 5 6 7 8 9 10

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 28 Jul 2017 19:35:46 +0000
From: michael@orlitzky.com
To: openldap-its@OpenLDAP.org
Subject: slapd should create its PID file before dropping privileges
Full_Name: Michael Orlitzky
Version: 2.4.45
OS: Gentoo
URL: 
Submission from: (NULL) (98.218.46.55)


The slapd daemon should create its PID file before dropping privileges. This
represents a minor security issue; additional factors are needed to make it
exploitable.

Why?

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 by init scripts that are run as root and
which blindly trust the contents of their PID files. If one daemon
flushes its cache in response to SIGUSR2 and another daemon drops all
connections in response to SIGUSR2, it is not hard to imagine a
denial-of-service by the user of the first daemon against the second.

Followup 1

Download message
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: michael@orlitzky.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Sat, 29 Jul 2017 15:55:29 +0100
michael@orlitzky.com wrote:
> Full_Name: Michael Orlitzky
> Version: 2.4.45
> OS: Gentoo
> URL:
> Submission from: (NULL) (98.218.46.55)
> 
> 
> The slapd daemon should create its PID file before dropping privileges.
This
> represents a minor security issue; additional factors are needed to make it
> exploitable.
> 
> Why?
> 
> 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.

Not sure this is a valid concern. The uid used to run services should not 
actually have a valid login shell, and thus should not ever be usable for any 
purpose other than running the daemon from init.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
From: Michael Orlitzky <michael@orlitzky.com>
Date: Sat, 29 Jul 2017 11:13:43 -0400
The problem scenario looks like the following:

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 open 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
   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.

7. Oops, the machine reboots, because I killed PID 1.



Followup 3

Download message
To: openldap-its@OpenLDAP.org
From: Michael Orlitzky <michael@orlitzky.com>
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
Date: Tue, 5 Sep 2017 13:51:21 -0400
This has been assigned CVE-2017-14159.



Followup 4

Download message
Date: Tue, 5 Sep 2017 14:38:01 -0700
From: Ryan Tandy <ryan@openldap.org>
To: michael@orlitzky.com
Cc: openldap-its@OpenLDAP.org
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
On Fri, Jul 28, 2017 at 07:35:47PM +0000, michael@orlitzky.com wrote:
>The slapd daemon should create its PID file before dropping privileges. This
>represents a minor security issue; additional factors are needed to make it
>exploitable.

If I understood you correctly, "Additional factors are needed" basically 
means you have to find a code execution vulnerability in slapd? At that 
point I think you can do much more interesting things - pretending that 
your user is uid 0, or in various admin groups are only the first ideas 
that come to mind.

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.

Howard pointed out on IRC that if the directory containing the pid file 
is sticky, making it owned by root means slapd can no longer remove it 
on exit. I'm not sure how common that is but it's a setup that works 
right now.



Followup 5

Download message
From: Michael Orlitzky <michael@orlitzky.com>
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: openldap-its@OpenLDAP.org
Cc: Ryan Tandy <ryan@openldap.org>
Date: Wed, 6 Sep 2017 07:38:18 -0400
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.


> Howard pointed out on IRC that if the directory containing the pid file 
> is sticky, making it owned by root means slapd can no longer remove it 
> on exit. I'm not sure how common that is but it's a setup that works 
> right now.

Typically the PID file would go directly in /run (or /var/run) and be
owned by root. That means that you can't clean it up when the daemon
exits, but no one expects a daemon to do that.

Practically, the PID file exists solely for the benefit of init systems.
Given the choice between,

  1. How do I determine if I can trust the contents of this file owned
     by an untrusted user?

  2. How do I remove the PID file after killing the daemon?

the second is much easier to do. The first is next to impossible to get
right; so if we have to pick one, that's the way to go IMO.



Followup 6

Download message
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: michael@orlitzky.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 6 Sep 2017 13:29:09 +0100
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.

> 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/



Followup 7

Download message
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: openldap-its@OpenLDAP.org
From: Michael Orlitzky <michael@orlitzky.com>
Cc: Howard Chu <hyc@symas.com>
Date: Wed, 6 Sep 2017 08:57:44 -0400
On 09/06/2017 08:29 AM, Howard Chu wrote:
> 
>> 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.
> 

Oh, it's one of /those/ daemons.


>>
>> 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.

Have you ever seen such an init script?

How should the init system know what process it was expecting to find,
if not by reading that process's PID from the PID file?

If you decide not to write the PID file as root, that's of course up to
you, but I still have to tell something to the people who ship OpenLDAP
as part of their distributions. I can tell them "Howard says it should
be easy," but considering that no one has ever done it, that's not real
helpful advice.

There are only two requirements really: it needs to be portable POSIX
sh, and the stop() function must only kill the one process created by
start(). If you give that a shot, you might see why I suggested that
this be fixed in slapd.



Followup 8

Download message
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: michael@orlitzky.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 6 Sep 2017 14:29:41 +0100
michael@orlitzky.com wrote:
> On 09/06/2017 08:29 AM, Howard Chu wrote:
>>> 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.
> 
> Have you ever seen such an init script?
> 
> How should the init system know what process it was expecting to find,
> if not by reading that process's PID from the PID file?

Learn something about Unix, please.

Use the ps command to verify that the process at least has the correct name. 
The init script should know it's looking for a process named slapd, not init.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 9

Download message
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: openldap-its@OpenLDAP.org
From: Michael Orlitzky <michael@orlitzky.com>
Cc: Howard Chu <hyc@symas.com>
Date: Wed, 6 Sep 2017 09:56:08 -0400
On 09/06/2017 09:29 AM, Howard Chu wrote:
> 
> Learn something about Unix, please.
> 
> Use the ps command to verify that the process at least has the correct
name. 
> The init script should know it's looking for a process named slapd, not
init.
> 

Supposing we want to copy/paste two or more "ps" calls into every slapd
init script, this still lets a hacker prevent his own hacked process
from being killed by writing junk into the file.

If the standard practice was to write the PID file as an unprivileged
user, we would need to not only copy/paste those "ps" calls into every
slapd init script, but literally every init script for every daemon.
Apparently my predecessors didn't want to do that, so the standard
practice is to write the PID file as root. Do with that information what
you will.



Followup 10

Download message
Subject: Re: (ITS#8703) slapd should create its PID file before dropping
 privileges
To: michael@orlitzky.com, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 6 Sep 2017 15:18:33 +0100
michael@orlitzky.com wrote:
> On 09/06/2017 09:29 AM, Howard Chu wrote:
>>
>> Learn something about Unix, please.
>>
>> Use the ps command to verify that the process at least has the correct
name.
>> The init script should know it's looking for a process named slapd, not
init.
>>
> 
> Supposing we want to copy/paste two or more "ps" calls into every slapd
> init script, this still lets a hacker prevent his own hacked process
> from being killed by writing junk into the file.
> 
> If the standard practice was to write the PID file as an unprivileged
> user, we would need to not only copy/paste those "ps" calls into every
> slapd init script, but literally every init script for every daemon.
> Apparently my predecessors didn't want to do that, so the standard
> practice is to write the PID file as root. Do with that information what
> you will.

Apparently your predecessors also didn't understand that PIDs get recycled. If 
your init scripts are just blindly trusting the contents of PID files they're 
all broken already. But none of that is of any concern of the OpenLDAP Project.

Closing this ITS as Invalid.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org